中国电子技术网
设为齐乐娱乐老虎机官网 网站地图 加入收藏
 
  1. MCU|FPGA|嵌入式|模拟设计|RF|电源管理|传感器|测试测量|LED|DSP|存储器|AC/DC转换器|DC/DC转换器|放大器|铁电存储|
  1. 智能汽车|智能可穿戴|齐乐娱乐老虎机官网|自动化与马达控制|人工智能|智能能源|智能电源|VR/无人机|智能手机|智能照明|智能医疗|5G技术
 
  1. 齐乐娱乐老虎机官网 > 技术文库 > ARM攒机指南-网络篇

ARM攒机指南-网络篇

关键词:ARM攒机 网络处理器 移动互联网 时间:2019-05-14 15:31:01       来源:网络

这一篇谈下网络处理器。

曾几何时,网络处理器是高性能的代名词。为数众多的核心,强大的转发能力,定制的总线拓扑,专用的的指令和微结构,许多优秀设计思想沿用至今。Tilera,Freescale,Netlogic,Cavium,Marvell各显神通。但是到了2018年,这些公司却大多被收购,新闻上也不见了他们的身影,倒是交换芯片时不时冒出一些新秀。

随着移动互联网的兴起,网络设备总量实际上是在增加的。那为什么网络芯片反而没声音了呢?究其原因有几点:

第一, 电信行业利润率持续减少。10年之前,Freescale的65纳米双核处理器,可以卖到40美金。如今同样性能的28纳米芯片,10美金都卖不到。而网络处理器的量并不大,低端有百万片已经挺不错了,高端更是可能只有几万片。这使得工程费用无法均摊到可以忽略的地步,和手机的动辄几亿片没法比。而单价上,和服务器上千美金的售价也没法比。这就使得网络处理器陷入一个尴尬境地。

第二, IP模式的兴起。利润的减少导致芯片公司难以维持专用处理器设计团队。电信行业的开发周期普遍很长,而网络处理器从立项到上量,至少需要5年时间,供货周期更是长达15年。一个成熟的CPU团队,需要80人左右,这还不算做指令集和基础软件的,全部加上超过100人。这样的团队开销每年应该在2000万刀。2000万刀虽然不算一个很大的数字,可如果芯片毛利是40%,净利可能只有10%,也就是要做到2亿美金的销售额才能维持。这还只是CPU团队,其余的支出都没包含。通常网络芯片公司销售额也就是5亿美金,在利润不够维持处理器研发团队后,只能使用通用的IP核,或者对原有CPU设计不做改动。另外,还要担心其他高利润公司来挖人。以Freescale为例,在使用PowerPC的最后几年,改了缓存设计后,甚至连验证的工程师都找不到了。

第三, 指令集的集中化。在五年前,网络处理器还是MIPS和PowerPC的世界,两个阵营后各有几家在支持。当时出现了一个很有趣的现象,做网络设备的OEM公司会主动告诉芯片公司,以后的世界,是x86和ARM指令集的世界,为了软件的统一,请改成ARM指令集。在当时,ARM指令集在网络界似乎只有Marvell一家在使用。而五年之后的现在,PowerPC和MIPS基本退出舞台,只有一些老产品和家用网关还有它们的身影。

在网络处理器领域,ARM并无技术和生态优势:技术上,MIPS大都是单核多线程的,支持自定义的指令集,对一些特定的网络包处理添加新指令。而PowerPC很早就使用了Cache

Stashing等专用优化技术,ARM直到近两年才支持。即使使用了ARM指令集,Cavium和Netlogic还是自己设计微结构。生态上,电信产品的应用层软件,都是OEM自定义的。底层操作系统,Linux和VxWorks,对MIPS和PowerPC的支持并不亚于ARM。而中间层的软件,虚拟机和数据转发,NFV等,网络芯片公司之前也并不是依靠ARM来维护的。赢得网络处理器市场还真是ARM的意外之喜。

第四, OEM公司自研芯片的崛起。思科,华为,中兴等公司,早就开始自己做技术含量高的高端芯片,或者量大的低端芯片。对于高端产品,只有使用自研芯片才能抢到第一个上市,对于低端产品,就主要是成本考虑了。

让我们看看网络处理器到底能应用在哪些场景:

首先,是终端设备(手机/基站,wifi,光纤/Cable/ADSL等),连接到接入网,然后再汇聚到核心网。就节点吞吐量而言,大致可以分为几类:

第一, 在终端,吞吐量在1Gbps级别,可以是手机,可以是光纤,可以是有线电视,也可以是Wifi,此时需要小型家庭路由器,无需专用网络加速器,对接口有需求,比如ATM,光纤,以太网或者基带芯片。

第二, 在基站或者边缘数据中心,吞吐量在1Tbps级别,此时需要边缘路由器,基站还需要FPGA或者DSP做信号处理。

第三, 在电信端,吞吐量远大于1Tbps,此时需要核心路由器,由专用芯片做转发。

以上场景中,低端的只需要1-2核跑所有的数据面和控制面程序就行;对于中端应用,控制面需要单核能力强的处理器,数据面需要能效高,核数众多的处理器和网络加速器;高端路由器需要专用asic进行数据面处理,同时使用单核能力强的处理器做控制面。

这其中比较有争议的是中端的数据面处理。对中断路由器来说,业务层的协议处理,毫无疑问的该使用通用处理器;而一些计算密集的功能,比如模板检测,加解密,压缩,交换等,还是用asic做成模块比较合适;对于队列管理,保序,优先级管理,资源管理等操作,就见仁见智了。从能效和芯片面积上来说,通用处理器做这些事肯定不是最优的,但是它设计容错性高,扩展性好,产品设计周期短,有着专用加速器无法取代的强项。硬件加速器本身会有bug,需要多次流片才能成熟,这非常不利于新产品的推广,而通用处理器方案就能大大减少这个潜在风险。专用网络加速器还有个很大的缺点,就是很难理解和使用,OEM如果要充分发挥其性能,一定需要芯片公司配合,把现有代码移植,这其中的推广时间可能需要几年。不过有时候芯片公司也乐见其成,因为这样一来,至少能把这一产品在某种程度上和自己捆绑一段时间。

再进一步,有些任务,如路由表的查找,适合用单核性能高的处理器来实现;有些任务,如包的业务代码,天然适合多线程,用多个小核处理更好。这就把通用处理器部分也分化成两块,大核跑性能需求强的代码,小核跑能效比需求强的代码。大小核之间甚至可以运行同一个SMP操作系统,实现代码和数据硬件一致性。事实上,有些网络处理器的加速器,正是用几十上百个小CPU堆起来的。

在网络芯片上,有两个重要的基本指标,那就是接口线速和转发能力。前者代表了接口能做到的数据吞吐量上限,后者代表了处理网络包的能力。

如上图,以太网包最小的长度是64字节,这只是数字部分的长度。考虑到PHY层的话,还有8字节的Preamble和开始标志,外加帧间分隔,总共84字节。

对于1Gbps的以太网,能够发送的以太网包理论上限是1.45Mpps(Million Packet Per Second)。相应的,处理器所能处理的包数只需要1.45Mpps,超出这个数字的能力是无用的。线速一定时,以太网包越大,所需的处理能力越低,所以在衡量处理器能力的时候,需用最小包;而在衡量网络接口能力的时候,需要用最大包,来使得帧间浪费的字段达到最小比例。

下面是Freescale的LX2160网络处理器的指标:

我们可以看到,共有24个28Gbps的Serdes口,对应的,2个100G以太网口需要8个Serdes口,而14个25G以太网口需要14个Serdes口,共22×25=550Gbps的吞吐率,最大需要800Mpps的处理能力。分散到16个核,每个核需要50Mpps的转发能力,对应到2.2Ghz的处理器,也就是44个时钟周期处理一个包。事实上,这是不现实的。通常,一个包经过Linux协议栈,即使什么都不做,也需要1500个时钟周期,就算使用专业转发软件,至少也需要80个左右。所以,最小64字节包只是一个衡量手段,跑业务的时候肯定需要尽量使用大包。

所以,在定义网络处理器的规格时,需要在线速和处理能力上做平衡。

上图是Freescale的LX2160网络处理器内部模块图。按照之前的线速和处理能力来看,可以分为三块:

第一, 处理器部分。这里是16个A72核,每两个放在一个组里,分配1MB二级缓存。在手机上,通常是四个核放在一组,这里为什么是两个?因为网络处理主要是针对包的各种处理,更偏重于IO和访存的能力,而不仅仅是计算。在处理包时,不光是网络包的数据需要读进处理器,还需要读入各种参数,来完成对包的处理。这些参数针对每个包会有所不同,缓存可能是放不下的,需要从内存读取。这就造成了需要相对较大的带宽。在架构篇,我们定量计算过,当只有一个处理器在做数据读取的时候(假设都不在缓存),瓶颈在核的对外接口BIU,而四个核同时读取,瓶颈在ACE接口。这就是每组内只放两个核而不是四个的原因。而处理器总的核数,很大程度上决定了网络处理器的包处理能力。

第二, 接口部分。网络处理器通常会把控制器(以太网,SATA,PCIe等)和高速串行总线口Serdes复用,做成可配置的形式,提高控制器利用率,节省面积。这里使用了24对差分线,每条通道支持25Gbps。高速串行总线设计也是一个难点,经常会有各种串扰,噪声,抖动等问题,搞不好就得重新流片。(推荐阅读: 又见山人:为什么串口比并口快? )

第三, 网络加速器,上图中的WRIOP和QB-Man属于网络加速器。这是网络处理器精华的设计,其基本功能并不复杂,如下图:

一个包从以太网进来,如果没有以太网加速器,那会被以太网控制器用DMA的方式放到内存,然后就丢给CPU了。而硬件加速器的作用,主要是对包的指定字段进行分析,打时间戳,然后分类并分发到特定的队列。而这些队列,在经过重映射后,会提供给CPU来处理。这其中还牵涉到队列关系,优先级,限速,排序,内存管理等功能。加解密模块可以看作独立的模块。就我所见,网络加速器需要和所有处理器之和相近的面积。

我们来看看一个包到底在网络处理器会经历哪些步骤:

首先,CPU调用以太网驱动,设置好入口(Ingress)描述符。以太网控制器根据描Ingress述符将Serdes传来的包,DMA到指定内存地址,然后设置标志位,让CPU通过中断或者轮询的方式接收通知。然后CPU把包头或者负载读取到缓存,做一定操作,然后写回到出口(Egress)描述符所指定的内存,并再次设置标志位,通知以太网控制器发包。Ingress和Egress包所存放的地址是不同的。以太网控制器根据Egress描述符将包发送到Serdes,并更新描述符状态。

将上述步骤实现到上图的系统中,并拆解成总线传输,是这样的(假定代码及其数据在一二级缓存中):

1. CPU写若干次以太网控制器(10-40GbE)的寄存器(Non-cacheable)

2. CPU读若干次以太网控制器(10-40GbE)的状态寄存器(Non-cacheable)

3. 以太网控制器(10-40GbE)进行若干次DMA,将数据从PHY搬到内存

4. CPU从内存读入所需包头数据,做相应修改

5. CPU写入内存所需数据

6. CPU写若干次以太网控制器(10-40GbE)的寄存器(Non-cacheable)

7. 以太网控制器(10-40GbE)进行若干次DMA,将数据从内存搬到PHY,并更新内部寄存器

8. CPU读若干次以太网控制器(10-40GbE)的状态寄存器(Non-cacheable)

以上8步所需时间通常为:

1. 1x以太网寄存器访问延迟 。假定为20ns。

2. 1x以太网寄存器访问延迟。假定为20ns。

3. 以太网控制器写入DDR的延迟。假设是最小包,64字节的话,延迟x1。如果是大包,可能存在并发。但是和第一步中CPU对寄存器的写入存在依赖关系,所以不会小于延迟x1。假定为100ns。

4. CPU从DDR读入数据的延迟。如果只需包头,那就是64字节,通常和缓存行同样大小,延迟x1。假定为100ns。

5. CPU写入DDR延迟x1。假定为100ns。

6. 1x以太网寄存器访问延迟 。假定为20ns。

7. 以太网从DDR把数据搬到PHY,延迟至少x1。假定为100ns。

8. 1x以太网寄存器访问延迟。假定为20ns。

2和3,7和8是可以同时进行的,取最大值。其余的都有依赖关系,可以看做流水线上的一拍。其中4,5和6都在CPU上先后进行,针对同一包的处理,它们无法并行(同一CPU上的不同包之间这几步是可以并行的)。当执行到第6步时, CPU只需要将所有非cacheable的写操作,按照次序发出请求即可,无需等待写回应就可以去干别的指令。这样,可以把最后一步的 所流水线中最大的延迟缩小到100+20+100共220ns以下的某个值。当然,因为ARM处理器上non-cacheable的传输,在对内部很多都是强制排序的,无法并行,总线也不会提早发送提前回应(early response),所以总延迟也就没法减少太多。

上面的计算意味着,CPU交换一下源和目的地址,做一下简单的小包转发,流水后每个包所需平均延迟是220ns。同时,增大带宽和CPU数量并不会减少这个平均延迟,提高CPU频率也不会有太大帮助,因为延迟主要耗费在总线和DDDR的访问上。提高总线和DDR速度倒是有助于缩短这个延迟,不过通常能提高的频率有限,不会有成倍提升。

那还有什么办法吗?一个最直接的办法就是增加SRAM,把SRAM作为数据交换场所,而不需要到内存。为了更有效的利用SRAM,可以让以太网控制器只把包头放进去,负载还是放在放DDR,描述符里面指明地址即可。这个方法的缺点也很明显:SRAM需要单独的地址空间,需要特别的驱动来支持。不做网络转发的时候,如果是跑通用的应用程序,不容易被利用,造成面积浪费。

第二个方法是增加系统缓存,所有对DDR的访问都要经过它。它可以只对特殊的传输分配缓存行,而忽略其余访问。好处是不需要独立的地址空间,缺点是包头和负载必须要指定不同的缓存分配策略。不然负载太大,会占用不必要的缓存行。和SRAM一样,包头和负载必须放在不同的页表中,地址不连续。

在有些处理器中,会把前两个方法合成,对一块大面积的片上内存,同时放缓存控制器和SRAM控制器,两种模式可以互切。

第三个方法,就是在基础篇提到的Cache stashing,是对第二种方法的改进。在这里,包头和负载都可以是cacheable的,包头被以太网控制器直接塞到某个CPU的私有缓存,而负载则放到内存或者系统级缓存。在地址上,由于缓存策略一致,它们可以是连续的,也可以分开。当CPU需要读取包头时,可以直接从私有缓存读取,延迟肯定短于SRAM,系统缓存或者DDR。再灵活一点,如果CPU需要更高层协议的包头,可以在以太网控制器增加Cache sashing的缓存行数。由于以太网包的包头一定排列在前面,所以可以将高层协议所需的信息也直接送入某个CPU一二级私有缓存。对于当中不会用到的部分负载,可以设成non-cacheable的,减少系统缓存的分配。这样的设计,需要把整个以太网包分成两段,每一段使用不同的地址空间和缓存策略,并使用类似Scatter-Gather的技术,分别做DMA,增加效率。这些操作都可以在以太网控制器用硬件和驱动实现,无需改变处理器的通用性。

此外,有一个小的改进,就是增加缓存行对CPU,虚拟机,线程ID或者某个网络加速器的敏感性,使得某些系统缓存行只为某个特定ID分配缓存行,可以提高一些效率。

以上解决了CPU读包头的问题,还有写的问题。如果包头是Cacheable的,不必等待写入DDR之后才收到写回应,所以时间可以远小于100ns。至于写缓存本身所需的读取操作,可以通过无效化某缓存行来避免,这在基础篇有过介绍。这样,写延迟可以按照10-20ns计算。

以太网控制器看到Egress的寄存器状态改动之后,也不必等待数据写到DDR,就可以直接读。由于存在ACE/ACE-lite的硬件一致性,数据无论是在私有缓存,系统缓存还是DDR,都是有完整性保证的。这样一来,总共不到50ns的时间就可以了。同理,Ingress通路上以太网控制器的写操作,也可以由于缓存硬件一致性操作而大大减少。

相对于第二种方法,除了延迟更短,最大的好处就是,在私有缓存中,只要被cache stashing进来的数据在不久的将来被用到,不用担心被别的CPU线程替换出去。Intel做过一些研究,这时间是200ns。针对不同的系统和应用,肯定会不一样,仅作参考。

让我们重新计算下此时的包处理延迟:

原来的第四步,CPU读操作显然可以降到10ns之下。

访问寄存器的时间不变。

CPU写延迟可以按照10-20ns计算。

总时间从220降到了50ns以下,四倍。

不过,支持Cache Stashing需要AMBA5的CHI协议,仅仅有ACE接口是不够的。CPU,总线和以太网控制器需要同时支持才能生效。如果采用ARM的CPU设计,需要最新的A75/A55才有可能。总线方面,A75/A55自带的ACP端口可用于20GB以下吞吐量的Cache Stashing,适合简单场景,而大型的就需要专用的CMN600总线以支持企业级应用了。还有一种可能,就是自己做CPU微架构和总线,就可以避开CHI/ACE协议的限制了。

Intel把cache stashing称作Direct Cache Access,并且打通了PCIe和以太网卡,只要全套采用Intel方案,并使用DPDK软件做转发,就可以看到80时钟周期,30-40ns的转发延迟。其中,DPDK省却了Linux协议栈2000时钟周期左右的额外操作,再配合全套硬件机制,发挥出CPU的最大能力。

这个40ns,其实已经超越了很多网络硬件加速器的转发延迟。举个例子,Freescale前几年基于PowerPC的网络处理器,在内部其实也支持Cache Stashing。但是其硬件的转发延迟,却达到了100ns。究其原因,是因为在使用了硬件加速器后,其中的队列管理相当复杂,CPU为了拿到队列管理器分发给自己的包,需要设置4次以上的寄存器。并且,这些寄存器操作无法合并与并行,使得之前的8步中只需20ns的寄存器操作,变成了80ns,超越CPU的数据操作延迟,成为整个流水中的瓶颈。结果在标准的纯转发测试中,硬件转发还不如x86软件来的快。

除了减少延迟,系统DDR带宽和随之而来的功耗也可以减少。Intel曾经做过一个统计,如果对全部的包内容使用cache,对于256字节(控制包)和1518字节(大包),分别可以减少40-50%的带宽。如下图:

当然,由于芯片缓存大小和配置的不同,其他的芯片肯定会有不同结果。

包转发只是测试项中比较重要的一条。在加入加解密,压缩,关键字检测,各种查表等等操作后,整个转发延迟会增加至几千甚至上万时钟周期。这时候,硬件加速器的好处就显现出来了。也就是说,如果一个包进来按部就班的走完所有的加速器步骤,那能效比和性能面积比自然是加速器高。但是,通常情况下,很多功能都是用不到的,而这些不常用功能模块,自然也就是面积和成本。

整理完基本数据通路,我们来看看完整的网络加速器有哪些任务。以下是标准的Ingress通路上的处理流程:

主要是收包,分配和管理缓冲,数据搬移,字段检测和分类,队列管理和分发。

Egress通路上的处理流程如下:

主要是队列管理和分发,限速,分配和管理缓冲,数据搬移。

在Ingress和Egress共有的部分中,最复杂的模块是缓冲管理和队列管理,它们的任务分别如下:

缓冲管理:缓冲池的分配和释放;描述符的添加和删除;资源统计与报警;

队列管理:维护MAC到CPU的队列重映射表,入队和出队管理;包的保序和QoS;CPU缓存的预热,对齐;根据预设的分流策略,均衡每个CPU的负载

这些任务大部分都不是纯计算任务,而是一个硬件化的内存管理和队列管理。事实上,在新的网络加速器设计中,这些所谓的硬件化的部分,是由一系列专用小核加C代码完成的。因此,完全可以再进一步,去掉网络加速器,使用SMP的多组通用处理器来做纯软件的队列和缓冲管理,只保留存在大量计算或者简单操作的硬件模块挂在总线上。

再来看下之前的芯片模块,我们保留加解密和压缩引擎,去除队列和缓存管理QB-Man,把WRIOP换成A53甚至更低端的小核,关键字功能检测可以用小核来实现。

网络处理上还有一些小的技术,如下:

Scattter Gather:前文提过,这可以处理分散的包头和负载,直接把多块数据DMA到最终的目的地,CPU不用参与拷贝操作。这个在以太网控制器里可以轻易实现。

Checksum:用集成在以太网控制器里面的小模块对数据包进行校验和编码,每个包都需要做一次,可以用很小的代价来替代CPU的工作。

Interrupt aggregation:通过合并多个包的中断请求来降低中断响应的平均开销。在Linux和一些操作系统里面,响应中断和上下文切换需要毫秒级的时间,过多的中断导致真正处理包的时间变少。这个在以太网控制器里可以轻易实现。

Rate limiter:包发送限速,防止某个MAC口发送速度超过限速。这个用软件做比较难做的精确,而以太网控制器可以轻易计算单位时间内的发送字节数,容易实现。

Load balancing, Qos:之前主要是在阐述如何对单个包进行处理。对于多个包,由于网络包之间天然无依赖关系,所以很容易通过负载均衡把他们分发到各个处理器。那到底这个分发谁来做?专门分配一个核用软件做当然是可以的,还可以支持灵活的分发策略。但是这样一来,可能会需要额外的拷贝,Cache stashing所减少的延迟优势也会消失。另外一个方法是在每一个以太网控制器里设置简单的队列(带优先级的多个Ring buffer之类的设计),和CPU号,线程ID或者虚拟机ID绑定。以太网控制器在对包头里的目的地址或者源地址做简单判断后,可以直接塞到相应的缓存或者DDR地址,供各个CPU来读取。如果有多个以太网控制器也没关系,每一个控制器针对每个CPU都可以配置不同的地址,让CPU上的软件来决定自己所属队列的读取策略,避免固化。

把这个技术用到PCIe的接口和网卡上,加入虚拟机ID的支持,就成了srIOV。PCIe控制器直接把以太网数据DMA到虚拟机所能看到的地址(同时也可使用Cache stashing),不引起异常,提高效率。这需要虚拟机中所谓的穿透模式支持IO(或者说外设)的虚拟化,在安全篇中有过介绍,此处就不再展开。同样的,SoC内嵌的以太网处理器,在增加了系统MMU之后,同样也可以省略PCIe的接口,实现虚拟化,直接和虚拟机做数据高效传输。

解决了负载均衡的问题,接下去就要看怎么做包的处理了。有几种经典的方法:

第一是按照包来分,在一个核上做完某一特征数据包流所有的任务,然后发包。好处是包的数据就在本地缓存,坏处是如果所有代码都跑在一个核,所用到的参数可能过多,还是需要到DDR或者系统缓存去取;也有可能代码分支过多,CPU里面的分支预测缓冲不够大,包处理程序再次回到某处代码时,还是会产生预测失败。

第二是按照任务的不同阶段来分,每个核做一部分任务,所有的包都流过每一个核。优缺点和上一条相反。

第三种就是前两者的混合,每一组核处理一个特定的数据流,组里再按照流水分阶段处理。这样可以根据业务代码来决定灵活性。

在以上的包处理程序中,一定会有一些操作是需要跨核的,比如对路由表的操作,统计数据的更新等。其中的一个重要原则就是:能不用锁就不要用锁,用了锁也需要使用效率最高的。

举个例子,如果需要实现一个计数器,统计N个CPU上最终处理过的包。首先,我们可以设计一个缓存行对齐的数据结构,包含若N+1个计数器,其中每一个计数器占据一行。每个CPU周期性的写入自己对应的那个计数器。由于计数器占据不同缓存行,所以写入操作不会引起额外的Invalidation,也不会把更新过的数据踢到DDR。最后,有一个独立的线程,不断读取前面N个计数器的值,累加到第N+1个计数器。在读取的时候,不会引起Invalidation和eviction。此处不需要软件锁来防止多个线程对同一变量的操作,因为此处计数器的写和读并不需要严格的先后次序,只需要保证硬件一致性即可。

在不得不使用锁的时候,也要保证它的效率。软件上的各种实现这里就不讨论了,在硬件上,Cacheable的锁变量及其操作最终会体现为两种形式:

第一, exclusive Access。原理是,对于一个缓存行里的变量,如果需要更新,必须先读然后写。当进行了一次读之后,进入锁定状态。期间如果有别的CPU对这个变量进行访问,锁定状态就会被取消,软件必须重复第一步;如果没有,就成功写入。这个原理被用来实现spinlock函数。根据硬件一致性协议MESI,处在两个CPU中的线程,同时对某一个变量读写的话,数据会不断在各自的私有缓存或者共享缓存中来回传递,而不会保持在最快的一级缓存。这样显然降低效率。多个CPU组之间的exclusive Access效率更低。

第二, 原子操作。在ARMv8.2新的原子操作实现上,修改锁变量的操作可以在缓存控制器上实现,不需要送到CPU流水线。这个缓存可以使私有缓存,也可以是共享的系统缓存。和exclusive access相比较,省去了锁定状态失败后额外的轮询。不过这个需要系统总线和CPU的缓存支持本地更新操作,不然还是要反复读到每个CPU的流水线上才能更新数据。我在基础篇中举过例子,这种做法反而可能引起总线挂起,降低系统效率。

如果一定要跑Linux系统,那么一定要减少中断,内核切换,线程切换的时间。对应的,可以采用轮询,线程绑定CPU和用户态驱动来实现。此外,还可以采用大页表模式,减少页缺失的时间。这样,可以把标准Linux内核协议栈的2000左右时钟周期缩到几十纳秒,这也就是DPDK和商业网络转发软件效率高的原因。

最后稍稍谈下固态存储。企业级的固态硬盘存储芯片,芯片基本结构如下:

如上图,芯片分为前端和后端两块,前端处理来自PCIe的命令和数据,并把数据块映射到最终nand颗粒。同时,还要做负载均衡,磨损均衡,垃圾回收,阵列控制等工作,略过不表。这些都是可以用通用处理器来完成的,差不多每1M的随机IOPS需要8个跑在1GHz左右的A7处理器来支撑,每TB的NAND阵列,差不多需要1GB的DDR内存来存放映射表等信息。其余的一些压缩,加解密等,可以通过专用模块完成。后端要是作为ONFI的接口控制器,真正的从NAND里面读写数据,同时做LDPC生成和校验。

如果单看前端,会发现其实和网络处理非常像,查表,转发,负载均衡,都能找到对应的功能。不同的是,存储的应用非常固定,不需要错综复杂的业务流程,只需处理几种类型的命令和数据块就可以了。

一个存储系统的硬件成本,闪存才是大头,占据了85%以上,还经常缺货。而闪存系统的毛利并不高,这也导致了固态存储控制器价格有限,哪怕是企业级的芯片,性能超出消费类几十倍,也无法像服务器那样拥有高利润。

一个潜在的解决方法,是把网络也集成到存储芯片中,并且跑Linux。这样,固态硬盘由原来插在x86服务器上的一个PCIe设备,摇身一变成为一个网络节点,从而省掉了原来的服务器芯片及其内存(可别小看内存,它在一台服务器里面可以占到三分之一的成本)。

如上图,可以把SPDK,DPDK,用户态驱动和用户态文件系统运行在一个芯片中,让一个网络包进来,不走内核网络协议栈和文件系统,直接从网络数据变成闪存上的文件块。在上层,运行类似CEPH之类的软件,把芯片实例化成一个网络存储节点。大致估算一下,这样的单芯片方案需要16核A53级别的处理器,运行在1.5GHz以下,在28纳米上,可以做到5-10瓦,远低于原来的服务器。

不过这个模式目前也存在着很大的问题。真正做存储芯片的公司,并不敢花大力气去推这种方案,因为它牵涉到了存储系统的基础架构变化,超出芯片公司的能力范畴,也不敢冒险去做这些改动。只有OEM和拥有大量数据中心互联网公司才能去定义,不过却苦于没有合适的单芯片方案。而且数据中心未必看得上省这点成本,毕竟成本大头在服务器芯片,内存以及机架电源。

  1. 分享到:
 
猜你喜欢
  1. 验证码: 点击换一张
  2. 注册|忘记密码?
  1.    看开发
  • 手把手教你设计蓝牙网状网络 蓝牙网状网络 (Bluetooth® mesh) 为支持多对多节点通信的低功耗无线网络技术,备受大型可扩展网络青睐,并已覆盖楼宇自动化和资产跟踪等领域。作为无线连接领域的领导者,Cypress率先推出了符合Bluetooth SIG的网状网络解决方案,并于近期推出了一款完全符合Bluetooth Mesh 1.0标准的超低功耗蓝牙5 MCU — CYW20819。 Mouser & Maxim  2019年07月11日     立即注册 预先提问

    可穿戴生物健康特征监测 可穿戴设备中添加心率监测功能已普遍可见,但是心率测试的准确度参差不齐,可穿戴市场的发展已经对准确度提出越来越高的要求,甚至要求医疗等级的准确度,除了心率监测之外,光电传感器能实现其他哪些更多的新功能,也是行业从业人士关注研究的领域。欧司朗光电半导体已有超过五年的时间关注健康监测领域,不断改进传感器设计,配合大客户,软硬件合作伙伴共同提高测试系统的准确度。现具备完整的产品线适配不同的设计方向。 Osram  2019年07月18日     立即注册 预先提问

    IO-LINK解决方案 IO-Link是首个开放式、现场总线无关、低成本、点对点的串行通信总线协议,用于与传感器及执行器通信,已经被采纳为国际标准(IEC 61131-9)。美信公司基于IO-Link技术开发了各种产品,有效地帮助客户解决系统设计难题。 Mouser & Maxim  2019年04月11日     视频回放 精彩问答

齐乐娱乐老虎机官网 中国电子行业研发工程师一站式服务平台 关于齐乐娱乐老虎机官网| 广告招商| 联系我们| 招聘信息| 友情链接| 齐乐娱乐老虎机官网导航| 手机齐乐娱乐老虎机官网 |   齐乐娱乐老虎机官网官方微博 Copyright © 2000- 齐乐娱乐老虎机官网 版权所有      粤ICP备17063136号-2      增值电信业务经营许可证粤B2-20050142      公安机关备案号44030402002188 Tel: 010-62985649, 0755-33322333     Fax: 0755-33322099
齐乐娱乐老虎机