首页 / 专利库 / 广播 / 数字视频广播 / 通信流量处理架构和方法

通信流量处理架构和方法

阅读:225发布:2020-05-13

专利汇可以提供通信流量处理架构和方法专利检索,专利查询,专利分析的服务。并且本 发明 揭露通信流量处理架构和方法。主中央处理单元(CPU)上的处理负载可以通过卸载 数据处理 任务至单独的 硬件 来减轻,此类技术作为互联网协议电视(IPTV)技术的出现以及 数字视频广播 (DVB)、路由器网关和数字录像机(DVR)机顶盒(STB)的汇聚给处理平台添加了不断增加的需求。,下面是通信流量处理架构和方法专利的具体信息内容。

1.一种集成式处理系统,其在集成电路包中,所述集成式处理系统包括:
主处理器,以通过基于包的协议根据从所述集成式处理系统外的外部组件接收的数据包执行与管理或控制包相关联的协议管理任务;
卸载子系统,以执行用于根据所述基于包的协议接收的数据包的数据处理任务;
接口,以确保与所述外部组件通信;以及
互连件,其耦合到所述主处理器、耦合到所述卸载子系统,并且耦合到所述接口,所述互连件确保所述主处理器和所述卸载子系统这两者通过所述接口与所述外部组件通信。
2.根据权利要求1所述的集成式处理系统,所述卸载子系统包括网络引擎以执行数据转发任务。
3.根据权利要求2所述的集成式处理系统,
所述网络引擎经配置以确定接收到的数据包是否与已知数据流相关联,以将所述接收到的数据包转发到其中所述接收到的数据包与已知数据流相关联的目的地,并且以将所述接收到的数据包转发到所述主处理器以用于其中所述接收到的数据包不与已知数据流相关联的流识别,
所述主处理器经配置以识别所述接收到的数据包与之相关联的数据流,其中所述接收到的数据包通过所述网络引擎被转发到所述主处理器,并且在所述网络引擎中将所述识别的数据流配置为已知数据流。
4.根据权利要求3所述的集成式处理系统,所述网络引擎经配置以确定所述接收到的数据包是否与已知数据流相关联,方法是确定所述接收到的数据包是否与在所述网络引擎中通过所述主处理器预先配置的数据流相关联。
5.根据权利要求3或权利要求4所述的集成式处理系统,所述主处理器是可操作的以在所述网络引擎中配置所述识别的数据流,方法是在储存在存储器中的流程表中配置所述识别的数据流。
6.根据权利要求3所述的集成式处理系统,数据流包括以下各项中的一者或一者以上:
特定类型的数据包;
与源相关联的数据包;以及
与目的地相关联的数据包。
7.根据权利要求1所述的集成式处理系统,所述卸载子系统包括安全引擎以执行用于接收到的数据包的安全相关任务。
8.根据权利要求7所述的集成式处理系统,所述安全引擎包括可配置的硬编码加密核心。
9.根据权利要求1所述的集成式处理系统,所述卸载子系统包括包引擎。
10.根据权利要求9所述的集成式处理系统,所述包引擎包括执行包引擎软件的另一处理器。
11.根据权利要求10所述的集成式处理系统,所述主处理器是第一处理器类型的并且所述另一处理器是不同于所述第一处理器类型的第二处理器类型的。
12.根据权利要求1所述的集成式处理系统,所述主处理器允许所述卸载子系统通过所述互连件对主处理器存储器高速缓存进行存取。
13.根据权利要求1所述的集成式处理系统,其进一步包括:
存储器,其耦合到所述互连件,以储存与所述主处理器和所述卸载子系统相关联的且通过所述主处理器和所述卸载子系统可读的对应的邮箱,
所述互连件确保所述主处理器将消息写入到与所述卸载子系统相关联的所述邮箱中并且确保所述卸载子系统将消息写入到与所述主处理器相关联的所述邮箱中。
14.根据权利要求1所述的集成式处理系统,所述外部组件包括通过软件驱动器可控制的外部组件,所述主处理器执行所述软件驱动器的第一部分,并且所述卸载子系统执行所述软件驱动器的第二部分。
15.根据权利要求1所述的集成式处理系统,所述接口包括可配置接口,所述可配置接口包括可配置用于结合多个不同物理接口中的任一个的操作的可配置组件。
16.根据权利要求15所述的集成式处理系统,所述可配置组件包括可通过所述主处理器配置的串行器/并行器(SerDes)。
17.根据权利要求16所述的集成式处理系统,所述多个不同物理接口包括外围组件互连高速(PCIe)接口、串行高级技术附件(SATA)接口以及通用串行总线(USB)接口。
18.根据权利要求1所述的集成式处理系统,通过所述卸载子系统执行数据包的数据处理任务,使得所述数据包无需通过所述主处理器。
19.一种处理方法,其用于集成电路包中,所述处理方法包括:
在集成电路包中提供主处理器以通过基于包的协议根据从集成式处理系统外的外部组件接收的数据包执行与管理或控制包相关联的协议管理任务;
在所述集成电路包中提供卸载子系统以执行用于根据所述基于包的协议接收的数据包的数据处理任务;
在所述集成电路包中提供接口以确保与所述外部组件通信;以及
在所述集成电路包中提供互连件,所述互连件耦合到所述主处理器、耦合到所述卸载子系统,并且耦合到所述接口,所述互连件确保所述主处理器和所述卸载子系统这两者通过所述接口与所述外部组件通信。
20.一种处理方法,其用于集成电路包中,所述处理方包括:
通过集成电路包中的主处理器通过基于包的协议根据从所述集成电路包外的外部组件接收的数据包执行与管理或控制包相关联的协议管理任务;
通过所述集成电路包中的卸载子系统执行用于根据所述基于包的协议接收的数据包的数据处理任务;以及
通过所述主处理器和所述卸载子系统这两者控制所述外部组件。
21.根据权利要求20所述的处理方法,
所述数据处理任务包括待执行用于特定类型的数据包的一或多个任务,所述方法进一步包括:
通过所述卸载子系统确定接收到的数据包是否是所述特定类型的数据包;
通过所述卸载子系统执行所述一或多个任务,其中所述接收到的数据包被确定为所述特定类型的数据包;
转发从所述卸载子系统接收到的数据包到所述主处理器以用于数据包类型识别,其中所述接收到的数据包的数据包类型未通过所述卸载子系统确定;
通过所述主处理器识别所述接收到的数据包的数据包类型,其中所述接收到的数据包被转发到所述主处理器;以及
在所述卸载子系统中配置所述所识别的数据包类型。
22.根据权利要求20或权利要求21所述的处理方法,其进一步包括:
在所述卸载子系统中配置可配置硬编码硬件以执行所述数据处理任务。
23.根据权利要求20所述的处理方法,其进一步包括:
允许所述卸载子系统对主处理器存储器高速缓存进行存取。
24.根据权利要求20所述的处理方法,
所述外部组件包括通过软件驱动器可控制的外部组件,
通过所述主处理器的所述执行包括执行所述软件驱动器的第一部分,
通过所述卸载子系统的所述执行包括执行与所述软件驱动器的第二部分相关联的任务。
25.一种处理架构,其在集成电路包中,所述处理架构包括:
主处理器,以通过无线保真(WiFi)协议根据从集成式处理系统外部的WiFi装置接收的数据包执行与管理或控制包相关联的协议管理任务;
卸载子系统,以执行用于根据所述WiFi协议接收的数据包的数据处理任务;
接口,以确保与所述WiFi装置通信;以及
互连件,其耦合到所述主处理器、耦合到所述卸载子系统,并且耦合到所述接口。
26.根据权利要求25所述的处理架构,其进一步包括:
网络引擎,其耦合到所述互连件,以执行以太网包的转发,
所述主处理器和所述卸载子系统各自包括WiFi驱动器隧道模以将WiFi包封装到以太网包中以用于通过所述网络引擎的所述主处理器与所述卸载子系统之间的交换。
27.根据权利要求25所述的处理架构,
所述主处理器经配置以执行上层WiFi驱动器软件,
所述卸载子系统经配置以执行下层WiFi驱动器软件,
所述下层WiFi驱动器软件使得所述卸载子系统转发未知的流的第一接收到的WiFi数据包到所述主处理器以用于流识别并且在通过所述主处理器的所述流的识别之后处理来自所述流的随后的包。
28.根据权利要求25到27中任一权利要求所述的处理架构,所述接口包括外围组件互连高速(PCIe)接口。
29.一种处理方法,其用于集成电路包中,所述处理方法包括:
在用于外围装置的驱动器软件中通过基于包的协议识别与管理或控制包相关联的协议管理任务,所述外围装置根据所述协议进行操作;
分离包括所述协议管理任务的所述驱动器软件的一部分与所述驱动器软件的剩余部分;
提供所述驱动器软件的所述剩余部分的实施方案;
提供软件适配层,其包括:上层接口,所述上层接口符合所述驱动器软件的所述部分与所述驱动器软件的所述剩余部分之间的接口;以及下层接口,所述下层接口符合所述驱动器软件的所述剩余部分的所述实施方案,以确保所述驱动器软件的所述部分在与所述驱动器软件的所述剩余部分的所述实施方案不同的硬件上执行。
30.一种集成式处理系统,其包括:
主处理器,以根据从所述集成式处理系统外的外部组件接收的数据执行与协议相关联的协议管理任务;以及
卸载子系统,其耦合到所述主处理器,以执行用于根据所述协议接收的并且与已知数据流相关联的数据的数据处理任务,所述卸载子系统经配置以确定所接收的数据是否与已知数据流相关联,以执行用于所述接收到的数据的其中所述接收到的数据与已知数据流相关联的数据处理任务,并且将所述接收到的数据转发到所述主处理器以用于其中所述接收到的数据不与已知数据流相关联的流识别,
所述主处理器经配置以识别所述接收到的数据与之相关联的数据流,其中所述接收到的数据通过所述卸载子系统被转发到所述主处理器,并且在所述卸载子系统中将所述识别的数据流配置为已知数据流。
31.一种处理方法,其用于集成电路包中,所述处理方法包括:
通过集成式处理系统中的主处理器根据从所述集成电路包外的外部组件接收的数据执行与协议相关联的协议管理任务;
通过耦合到所述集成式处理系统中的所述主处理器的卸载子系统确定根据所述协议接收的数据是否与配置在所述卸载子系统中的已知数据流相关联;
通过所述卸载子系统执行用于所述接收到的数据的数据处理任务,其中所述接收到的数据与已知数据流相关联;
将从所述卸载子系统接收到的数据转发到所述主处理器以用于数据流识别,其中所述接收到的数据不与已知数据流相关联;
通过所述主处理器识别所述接收到的数据与之相关联的数据流,其中所述接收到的数据被转发到所述主处理器;
通过所述主处理器配置所述识别的数据流作为所述卸载子系统中的已知数据流;以及通过所述卸载子系统执行用于与所述识别的数据流相关联的随后接收到的数据的数据处理任务。

说明书全文

通信流量处理架构和方法

[0001] 相关申请案的交叉参考
[0002] 本申请案涉及并且主张2012年12月26日递交的第61/745,951号美国临时专利申请案的权益。

技术领域

[0003] 本发明大体上涉及通信,并且具体而言涉及通信流量处理。

背景技术

[0004] 此类技术作为互联网协议电视(IPTV)技术的出现以及数字视频广播(DVB)、路由器网关和数字录像机(DVR)机顶盒(STB)的汇聚给处理平台添加了不断增加的需求。附图说明
[0005] 现在将参考附图更详细地描述本发明的实施例的实例。
[0006] 图1是实例处理架构的框图
[0007] 图2是实例处理器复合体的框图。
[0008] 图3是实例网络引擎的框图。
[0009] 图4是实例卸载/加速子系统的框图。
[0010] 图5到9是其它实例处理架构的框图。
[0011] 图10说明分区装置驱动器的实例。
[0012] 图11是说明低速接口的框图。
[0013] 图12是说明高速接口的框图。
[0014] 图13是说明实例多服务系统的框图。
[0015] 图14是说明实例网关的框图。
[0016] 详细说明
[0017] 多服务处理提供于可以同时传递用于安全数据、语音、视频和移动服务的线速率带宽而没有服务降级的单个输送平台中。
[0018] 数据网络连接和应用处理一起集成到单芯片或集成电路包中。特征可以包含柔性(flexible)的硬件设计、多个数据接口、与卸载硬件结合的一或多个通用主处理器,以及有效处理器间通信。
[0019] 可以提供专用处理器、多个处理器和/或专业化硬件以确保硬件卸载或加速从而用于处理密集功能。举例来说,此方法从主通用处理器(也称为应用处理器或主CPU)卸载功能、保留CPU处理能用于额外的附加值服务。
[0020] 处理平台中的通用主中央处理单元(CPU)可以加载到在执行网络连接或数据通信任务中用于执行例如应用等其它任务或服务相关任务所经受的剩余的容量的此类程度。考虑网络连接的性能保持可能会以有限的或降级的应用或服务性能为代价。举例来说,网络连接任务可以占据主CPU处理周期的75-80%,留下可用于应用或服务处理的有限的资源。
[0021] 主CPU资源的此类高利用率还可以对功率消耗和/或操作温度造成影响。举例来说,STB中的主CPU将是较高功率组件中的一者,并且很可能是在此类装置中具有最高潜在功率消耗的组件。
[0022] CPU的实际功率消耗取决于其利用率,并且相应地高利用率将具有高相关联的功率消耗。高利用率还增加了产热,对散热片或其它温度控制措施添加了额外的需求。通过本文所揭示的专用的可配置的引擎的使用可以获得相当大的效率。
[0023] 处理架构实例
[0024] 图1是实例处理架构的框图。
[0025] 图1中所示的实例架构100是具有两个主CPU 102、104的双重处理器主CPU架构。也可以提供各种接口中的任何接口。在实例架构100中,存在多个接口。这些包含:
[0026] 三个外围(Peripheral)组件互连高速(PCIe)或串行高级技术附件(SATA)接口118、120、122,其表示共享同一物理层(PHY)接口组件的三组PCIe控制器和SATA控制器;
[0027] SATA接口124;
[0028] USB主机接口126;
[0029] 通用串行总线(USB)主机/装置接口128;
[0030] 液晶显示器(LCD)接口130;
[0031] 同步串行端口(SSP)接口132,其可配置为支持单个接口或两个同步PCM接口的脉冲编码调制(PCM)接口、IC间声音(I2S)总线接口或索尼/飞利浦数字互连格式(SPDIF)接口;
[0032] I2C(IC间)总线接口134;
[0033] 安全数字(SD)接口136;
[0034] 一组接口138,其包含联合测试行动小组(JTAG)接口、在此实例中选择为具有多达5个芯片的串行外围接口(SPI)和通用输入输出(GPIO)接口的实例;
[0035] 四个通用异步收/发器UART接口140;
[0036] 快闪存储器接口142;
[0037] 传输流接收(Rx)接口144,其在此实例中支持多达6个传输流;以及[0038] 千兆比特媒体存取控制器(GMAC)接口146、148、150。
[0039] 图1还示出了例如当部署在STB中时这些接口中的一些可能耦合到的组件的实例。在示出的实例中,这些组件包含802.11n无线模、用户线路接口控制器(SLIC)、快闪存储器、射频(RF)调谐器、家庭电话网络连接联盟(FIPNA)适配器、开关和物理层(PHY)组件以及无线调制解调器。在其它实施例中,除图1中所示的那些之外或替代于图1中所示的那些,其它类型的组件可以耦合到接口。
[0040] 实例架构100还可包含256kBL2高速缓存152、8kB安全启动只读存储器(ROM)154、高速缓存一致性端口156、网络引擎158、安全引擎160、包引擎162、流量管理器164、直接存储器存取(DMA)控制器165、256kB包缓冲器166和16位或32位双数据速率(DDR)存储器控制器168。在其它实施例中,除图1中所示的实例存储器尺寸和类型之外或替代于图1中所示的实例存储器尺寸和类型,可以提供其它尺寸和/或类型的存储器。
[0041] 应了解图1的实例架构100以及其它附图的内容仅意图用于说明性目的,并且本发明绝不限于附图中明确示出的且在本文中描述的特定实例实施例。
[0042] 实例架构100中的全部的组件可以集成到同一芯片或集成电路包中,或跨越多个集成电路。单芯片或包于是包含网络连接组件和数据处理组件这两者。举例来说,特定的处理任务可以被指派到网络引擎158、安全引擎160和/或包引擎162中的不太大功率的且更具功率效率的处理器,由此在可用于执行例如应用等其它任务或服务相关任务的更大功率的通用主CPU 102、104上形成处理周期。
[0043] 这种类型的架构可以通过减小针对可以在针对它们的特定的任务优化的不太大功率处理器中执行的任务的主CPU 102、104利用率而更具功率效率。性能增益还可通过使更多的主CPU 102、104处理周期可用于执行其它任务而实现。
[0044] 举例来说,假设安全任务从主CPU 102、104卸载到安全引擎160,那么主CPU具有可用于应用或服务相关任务的更多处理周期。虽然具有主CPU架构的装置可能提供用于与具有基于实例架构100的架构的装置类似或甚至相同的数据速率,但是由于到一或多个引擎158、160、162的任务卸载,作为更好的主CPU可用性的结果,具有基于实例架构100的架构的装置可能支持更加特征丰富的应用或服务和/或更好的应用/服务响应时间。
[0045] 这说明了用于服务供应商网络中的较高性能的硬件加速特征。在一个实施例中,硬件加速特征通过定制的软件装置驱动器存取,这使得硬件对上层软件组件和应用透明。例如,在Linux环境下,可以使用开源驱动器和略微地修改内核。这允许用户在Linux环境下进一步定制内核并且运行软件应用程序。其它操作系统可以支持使用此类型的硬件抽象方法。
[0046] 实例架构100集成加速硬件用于网络引擎158中的网络连接操作、安全引擎160中的安全以及包引擎162中的例如传输流聚集等包处理操作。网络连接操作可以包含例如以下各项中的一或多个∶分类和存取控制列表(ACL)处理、虚拟局域网(VLAN)操作、说明性地通过Linux QDisc模型的服务质量(QoS)、转发、网络地址转译(NAT)/网络过滤器操作、多播,和/或排队/调度。可以从主CPU 102、104卸载到实例架构100中的安全引擎160的特征和相关处理可以包含以下各项中的一或多个∶互联网协议安全(IPSec)、数字传输内容保护(DTCP)、安全实时传输协议(SRTP)和/或安全套接字层(SSL)。
[0047] 上述内容提供了如图1所示的实例架构100的大体描述。借助于以下实例讨论其它细节。
[0048] 处理器复合体
[0049] 在一个实施例中,主处理器102、104中的每一个是可在市面上购得的通用处理器。说明性处理器速度是600MHz到750MHz。32kB层1或L1指令(I)和数据(D)高速缓存110、112和
114、116在图1中示出。主CPU可以支持其它特征,例如用于减小的代码尺寸的软件加速以及应用加速、用于单个或多个操作系统(O/S)应用的不对称多处理(AMP)和对称多处理(SMP)、用于图形/计算处理的单指令多数据(SIMD)指令集、JTAG/程序跟踪接口(PTM)、性能监测和/或缓冲以例如加速虚拟地址转译。本发明不限于任何特定的主CPU或主CPU的类型。并且,虽然实例架构100是双重CPU架构,但是本发明的各方面可以在单个CPU架构中应用和/或在具有两个以上主CPU的架构中应用。
[0050] 在一个实施例中的主CPU 102、104的配置涉及在配置寄存器中的设置配置参数。当每个主CPU 102、104在重置之后启动时,它将读取其配置参数。除用于主CPU核心102、104的默认配置之外,这些参数也可能提供L2高速缓存152的默认配置。为了改变配置参数,对适当的寄存器进行修改并且将重新启动或重置发布到主CPU 102、104中的一或两者。在一个实施例中,系统中的寄存器是存储器映射的。配置参数随后可以通过写入到每个寄存器已经在存储器空间中被指派的地址而得到修改。
[0051] 图2是实例处理器复合体的框图。此实例200包含图1中所示的许多组件并且具有一些额外的组件。所述额外组件包含:
[0052] 全局控制接口270,通过所述全局控制接口中断和/或其它控制信号可以提供到主CPU 102、104和其它组件;
[0053] 动态可控制的柔性的互连件272,其例如可以使用一或多个切换结构实施;
[0054] 网络引擎控制模块274;
[0055] 功率/消费性红外线(CIR)/实时时钟(RTC)接口276,以确保手动开/关切换、通过红外线远程控制装置的控制和基于计时器的控制;
[0056] 串行器/并行器(SerDes)控制器278,通过所述控制器主CPU 102、104和/或其它组件如下文中进一步描述控制SerDes组件的配置;以及
[0057] “通用外围装置”块280,其大体上表示外围接口,例如,图1中所示的GMAC、UART、SPI和GPIO接口。
[0058] 如图2中示出,主CPU 102、104通过柔性的互连件272耦合到各种接口以及连接到那些接口的任何外围装置。网络引擎158、安全引擎160和包引擎162还通过柔性的互连件272耦合到接口和外围装置,并且可以直接与那些外围装置通信并且直接控制那些外围装置。通过柔性的互连件272、包含主CPU 102、104和实施网络引擎158的卸载子系统中的单独的“卸载”处理器或硬件的系统中的任何处理器,安全引擎160和/或包引擎162例如可以控制系统中的任何资源。这允许系统软件分配哪些处理器将控制运行时间的哪些输入/输出(I/O)。当相关联的处理从主CPU 102、104卸载时,这继而确保单独的卸载处理器或硬件控制高带宽SerDes I/O,例如PCIe接口。
[0059] 图2还示出了在主CPU 102、104处的高速缓存一致性外围输入端。在一个实施例中,主CPU 102、104中的每一个具有高速缓存一致性端口。为了提供完整的I/O一致性,可以将特定存储器地址指派到高速缓存一致性端口。高速缓存一致性端口上的读取可以命中任何主CPU的L1数据缓存,并且高速缓存一致性端口上的写入可以使L1高速缓存中的任何过期数据失效并且透写到L2高速缓存152。这可以提供相当大的系统性能益处和功率节省,并且还可以简化驱动器软件。装置驱动器不再需要执行高速缓存清洁或冲洗来确保L2/L3存储器系统是最新的。下文中将进一步详细讨论高速缓存一致性。
[0060] 网络引擎
[0061] 图1和2中所示的网络引擎158可以提供此类特征作为高速包转发、编辑、排队、成形和监管。网络引擎158可以切换、路由并且执行例如以太网承载点对点协议(PPPoE)穿隧和传输控制协议(TCP)分段等包服务而无需主CPU干预,由此从主CPU 102、104中卸载这些网络连接任务。
[0062] 图3是实例网络引擎的框图。实例网络引擎300包含入口302和出口网络接口310、转发引擎304、队列管理器306和调度器308。在一个实施例中,实例网络引擎300以可配置的但是硬编码的硬件实施。
[0063] 为了便于参考,还示出了实例网络引擎300与其相互作用的其它组件。这些其它组件包含存储器312、一或多个卸载/加速引擎处理器316、DMA控制器165,以及主CPU102、104。存储器312包含一或多个存储器装置。在一个实施例中,存储器312包含DDR存储器。
[0064] 在一个实施例中,实例网络引擎300可以使用多个转发表以在Linux IP堆栈中实现包转发方案。Linux规则和流程表都可以在硬件中实施。规则表是基于信息在当前包中发现的。一些基于规则的项,例如,防火墙项,可以通过系统软件在流量开始流动之前得到配置。可以容纳到其它操作系统或定制的转发堆栈的适配。
[0065] 当接收到流中的第一包时流程表可以通过系统软件编程,并且用于该流的每个随后的包可以随后由实例网络引擎300处理而不具有主CPU 102、104的干预。不匹配的包可以被发送到主CPU 102、104以基于过滤选项丢弃或起始学习过程。选择的流中的包可以转发至主CPU 102、104,例如,前提是与流相关联的有效负载需要更深入的包检查;前提是使用实例网络引擎300用于加速的硬件流的总数超过特定数目的硬件流;和/或前提是基于任何组合的任何包字段的硬件查找的数目超过特定数目的查找。在一个实施例中,在选择性流转发至主CPU 102、104之前实例网络引擎支持多达8192个硬件流和12000个硬件查找。使用实例网络引擎300的硬件加速还可以在每个流/规则基础上开启或关闭。
[0066] 基于Linux的流连接可以通过内核建立并且随后编程到硬件表中。此网络引擎模型允许Linux内核和网络连接应用以作出用于新流的全部决策。
[0067] 如本文所引用的数据流或流可以与共享多少一些共同特征的数据相关联。举例来说,某些数据处理任务可能是在某一类型的数据上执行的。如本文所揭示,当某一数据类型首先遇到主CPU、102、104并且被主CPU 102、104所识别时,用于该类型的数据的数据流可以随后得到配置,使得该类型的随后接收到的数据可以被识别为与已知数据流相关联并且相应地在卸载子系统中得到处理而无需主CPU的参与。数据类型是可以区分不同数据流的特征或图案的一个说明性实例。其它实例包含发送或源地址和/或目的地地址。
[0068] 实例网络引擎300的操作进一步借助于以下实例来说明。
[0069] 假设包示意性地通过以太网GMAC接口146、148、150(图1)中的一者到达入口网络接口302中,但是不是已知流量流的一部分。未知的流可以丢弃或转发至主CPU102、104以进行检查。如果包被丢弃,那么将不会发生其它事情。出于说明的目的,此实例考虑其中接收到的包被转发至主CPU 102、104以用于检查的情境。
[0070] 在一个实施例中,包已经到达被称作物理源端口ID(PSPID)的ID,并且所述包、一些早期L2分析信息和时戳被传递到转发引擎304。转发引擎304可以执行查找的若干阶段:
[0071] ·PSPID到Logical源端口ID(LSPID)映射-此映射可能应用于,例如,在例如端口聚集的情况下其中存在物理端口与虚拟端口之间的过渡的情况。在此实例中转发引擎304本身理解LSPID同时网络接口302作用在PSPID上。
[0072] ·包分类-如果例如包去往上游或来自上游用户端口(用户网络接口-UNI)或包来自网络下游的服务供应商侧,那么分类在所述包上执行。通过分类,确定了包上的服务或总体操作。
[0073] ·在一个实施例中,服务数据库或SDB基于转发分类设置将在所述包上执行的检索的类型以及一些总体配置。
[0074] ·接下来发生的是散列和最长前缀匹配搜索。这些可以确定如何转发所述包、如何设置QoS等等。如果需要NAT,它们继而指向IP和媒体存取控制(MAC)地址表以决定包标头中的何者需被替代。
[0075] ·在一个实施例中,还存在VLAN成员资格表以作为用于二层转发搜索的VLAN的成员分配端口。
[0076] ·最后,VLAN和QoS结果表允许包的修改以用于添加/移除VLAN以及改变QoS值。
[0077] 查找的结果是基于它们的命中和那些结果之间的优先级映射决定的。基于转发查找的结果,转发引擎304可以修改包以用于传输。即使包标头是未修改的,也可以确定并且考虑得到转发的包的方面(例如,转发到主CPU队列)、监管指数等。
[0078] 基于ACL,转发结果可以发生改变或被覆写。
[0079] 作为一个实例,ACL可以被设置为观察包类型并且覆写不同于ACL中的默认动作的任何转发引擎动作。ACL项还可以在逻辑上链接在一起。举例来说,可以写下若干ACL项用于不同动作,与它们的结果“与(AND)”在一起以形成那些ACL规则的超集。
[0080] 返回到来自未知流的包的实例,并且假定出于说明的目的不存在规定不同动作的ACL,这是由于此特定包错过了正常转发到转发引擎端口(在此实例中它不是已知流的一部分),它被放置到意图用于主CPU 102、104的虚拟输出队列(VOQ)中。
[0081] 在图3中所示的实例中此入队是通过队列管理器306并且进入到存储器312中的。包将驻留在VOQ中直至它随着通过调度器308命令而出队以用于调度包离开主CPU队列。
[0082] 一旦调度器308使包出队,则主CPU 102、104使包从存储器312中的队列中出队,要么通过接口到存储器要么到DMA控制器165。所述包随后由主CPU 102、104进行分析。出于此实例的目的,假设包的检查识别新流,并且主CPU 102、104决定所述包应该通过一些变换而转发到转发引擎304端口上。转发引擎304允许变换的包在该端口上传送通过。主CPU 102、104可以在此时实际上向外转发变换的包使得它不会丢失,或者如果帧丢失不是关注点的话则等待直至下一个帧。如上文所指出,柔性的互连件272(图2)确保包含主CPU 102、104和卸载子系统的系统中的任何处理器与任何资源通信并且假定对任何资源进行控制,并且因此主CPU 102、104可以转发变换的包。在此实例中主CPU 102、104还将更新流程表。
[0083] 下一次相同类型的包在入口网络接口302上接收,转发引擎304现在具有转发表中的命中(在分类之后),预先确定的包变换发生并且包得到修改,并且出方向VOQ标记到出口网络接口310端口,示意性地是以太网端口。
[0084] 包是现在列队到队列管理器306硬件VOQ中的,所述包将在到期时通过调度器308而出队。如在调度器308中配置的上游或下游VOQ使去往以太网端口的包出队。队列管理器306将包传送到出口网络接口310上。随着包出队,可以示意性地通过校验循环冗余校验(CRC)代码执行错误校验,以确保存储器的错误(软错误)尚未在包上发生。错误校验可以通过队列管理器306或另一元件执行。如果错误校验不通过,则包可以任选地使其CRC代码戳记为无效的,因为实际上将其发出以确保另一侧将接收错误并且丢弃帧。包随后在传输端口上排队并且发出。
[0085] 如上文所指出,在转发过程期间包可以发生变换。包变换或编辑功能可以包含,例如:
[0086] ·针对TCP和用户数据报协议(UDP)包的源和目的地端口修改
[0087] ·PPPoE/PPP标头插入/移除
[0088] ·MAC源地址(SA)/目的地地址(DA)修改和取代
[0089] ·针对IPv4和IPv6的IP源/目的地地址修改
[0090] ·当前IP选项和/或延伸标头的保留
[0091] ·QoS字段修改,例如802.1p/差分服务码点(DSCP)-服务的类型(ToS)[0092] ·一或两个VLAN对上的VLAN操作(QinQ支持)
[0093] ·IPv4标头校验和的更新
[0094] ·L4(TCP或UDP)标头校验和的更新。
[0095] 考虑PPPoE/PPP封装/解封装的实例。此实例不仅说明包变换,而且说明转发引擎304与卸载/加速引擎处理器316之间的相互作用。
[0096] 当在主CPU 102、104上运行的软件接收在流中的第一PPPoE包时,它配置转发引擎304的流程表中的流以从广域网(WAN)接口中移除PPPoE/PPP标头。它随后配置转发引擎304流程表中的另一流以添加PPPoE/PPP标头用于去往WAN的流量,并且此后在这个流中的每个包仅由硬件处理。
[0097] 为了对PPPoE/PPP包进行解封装,转发引擎304在包标头中设置位以告知包引擎(在此实例中由卸载/加速引擎处理器316支持)从PPPoE/PPP到IPv4/IPv6转换包。在包可以转换成IPv4或IPv6包之前,所述包必须具有0x8864的以太网类型或者要么0x0021要么0x0057的PPP类型。在转换期间,以太网类型由用于IPv4的0x0800或用于IPv6的0x86DD替换。接下来的6个字节:PPPoE标头(V、T、代码、会话标识符和长度)以及PPP类型全部被剥离。
[0098] 包解封装与VLAN标记的包一起工作。包引擎也可以能够解析封装PPP类型以外的包的IP部分。这允许针对PPPoE/PPP包的IP/VLAN/MAC操作。
[0099] 在包引擎下IP/VLAN和MAC操作是可供使用的,在此实例中包引擎负责将包封装到PPPoE/PPP中。转发引擎304可以基于其流结果识别封装哪个包。包引擎可以随后使用来自流的会话ID,所述包引擎还供应有内部包的IP版本,以封装所述包。在此实例中包含版本、类型和代码的以太网类型和PPPoE字段在转发引擎304中配置。
[0100] 以下是字段设置的实例:
[0101] ·版本=1
[0102] ·类型=1
[0103] ·代码=0。
[0104] PPPoE版本、类型和代码字段组成16位标头,所述标头通过包引擎插入到原始包中用于封装。
[0105] 还插入了会话ID、长度和PPP类型。长度字段是包含PPPoE标头和包的其余部分的包的长度。
[0106] 在此实例中,主CPU 102、104涉及在转发引擎304流程表的初始流识别和配置中。一旦流程表已经配置好,则封装/解封装任务和安全任务(如果存在的话)通过卸载/加速处理器316执行。封装/解封装和安全任务是本文所揭示的数据处理任务的实例,并且可以占据主CPU 102、104上的许多处理周期,留下可用于其它任务的较少处理周期。卸载这些任务到卸载/加速处理器316减少主CPU 102、104上用于执行数据处理任务的处理负载。
[0107] 卸载/加速引擎处理器316与转发引擎304的相互作用可以通过VOQ如上文所述在包的情况下被转发到主CPU 102、104以用于检查。在一个实施例中,存在用于包引擎的一个端口和用于安全引擎的一个端口,并且这些端口中的每一个具有由调度器308控制且可设置为目的地VOQ的八个队列。一旦包到达包引擎或类似地安全引擎中,包经处理并且其标头可以通过包引擎修改、通过安全引擎加密或解密等等。最后,处理过的包可以示意性地通过卸载/加速引擎处理器316的机载局部DMA控制器移动离开包引擎端口或安全引擎端口或离开回到存储器312。在此实例中,此类型的端口和队列布置提供主CPU 102、104与卸载/加速引擎处理器316之间的有效的处理器间通信。
[0108] 更详细地考虑排队,如上文所指出,实例网络引擎300使用VOQ来识别哪个包队列在等待传输的同时储存包。在一个实施例中,存在112个VOQ。当包通过例如GMAC 146、148、150(图1)、主CPU 102、104或其它源等任何源接收时,它们被传递到转发引擎304,所述转发引擎最后决定包是否被丢弃或转发(在适当时修改)。如果包将被转发,那么转发引擎304识别将保持包直至它通过调度器308调度而离开的队列。对于例如Linux等操作系统,这可以通过允许用于包的调度的流量控制模块进行控制。
[0109] 举例来说,每个端口可以存在多个队列,以为例如语音、视频和受控制的消息等优先流量提供QoS。在一个实施例中,队列提供用于全部千兆比特端口、包引擎(用于例如IP分段重新组装、IPSec等任务)、包复写(根调度器)和主CPU 102、104。主CPU 102、104还可以具有大量队列以支持用于不同类型的流量的各种优先级。举例来说,可以对用户类型进行分类以支持高端企业类型应用。
[0110] 在实例网络引擎300中的队列管理器306接受来自转发引擎304的包并且将它们储存到存储器312中的队列中。队列管理器306可以经配置以随着它管理存储缓冲器而维持优先和服务等级。
[0111] 调度器308可以提供如下的此类特征:
[0112] ·严格优先级(SP)服务
[0113] ·赤字轮询(DRR)调度服务
[0114] ·支持多播服务的根队列
[0115] ·每物理端口的SP/DRR队列的组合层级
[0116] ·处理端口、根队列的主调度器和主CPU调度器。
[0117] 各种调度类型中的任何一个并且可能地多个调度类型可以由调度器308提供。在一个实施例中,调度器308实施层级调度。举例来说,根队列调度器、主CPU调度器和每端口调度器可以全部调度流量队列到最高级调度器。较低级别调度器可以各自调度SP队列和DRR队列。DRR调度器可以从DRR队列调度流量,其中SP队列和DRR调度队列随后在馈送到最高级调度器中的下一个级别的SP或DRR调度器中得到调度。对于全部的端口每端口调度器可以馈送到再下一个级别的调度器中,所述再下一个级别的调度器示意性地是轮询(RR)调度器,其馈送到最高级调度器中。
[0118] SP调度服务全部根据它们的优先级排队。较高优先级队列在较低优先级队列之前得到服务。语音和视频应用可以通过高优先级队列中的低抖动、时延和丢包服务。虽然SP调度很好地服务高优先级应用,但是较低优先级包可能是饥饿的。为了解决这个问题,包监管器和/或整形器可以用于最高优先级服务,而DRR调度用于其余服务。使用DRR允许带宽在所有服务中共享同时保持QoS。权重可以根据用户要求应用于不同优先级。
[0119] 虽然在图3中未专示出,但是流量管理器164(图1)可以用于控制包和排队参数的监管。它还可以提供决定何时基于队列深度在链路上发送暂停帧的能力和/或其它流量管理功能。
[0120] 在一个实施例中,还提供了拥塞避免特征。举例来说,加权随机及早丢弃(WRED)功能可以基于平均队列深度(AQD)确定用于流量队列的包丢弃概率。AQD可以通过软件可配置的权重计算,并且线性丢弃配置文件可以由例如最小AQD、最大AQD和最大丢弃概率拦截点定义。背压是可以用于减少或避免拥塞和/或由于拥塞的包丢弃的特征的另一实例。这种类型的功能可以在队列管理器306或可能地其它地方中实施。
[0121] 其它特征还可以或实际上由网络引擎提供。上述内容仅意图出于说明的目的。
[0122] 卸载/加速子系统
[0123] 图4是实例卸载/加速子系统400的框图。实例子系统400包含:包接口402、一或多个包引擎处理器404、一或多个安全引擎408、存储器块410、DMA控制器412、安全联盟(SA)数据库414和非包接口416。虽然在图1和2中单独地示出安全引擎160和包引擎162,但是实例子系统400实施这些引擎中的两者。
[0124] 在此实例中,包接口402确保实例子系统400与其它组件至少交换数据、包。通过包接口402,可能从流量队列中接收包以用于处理,并且在处理之后将包返回到队列或其它组件。
[0125] 包接口402或可能地另一接口可以支持其它类型的信号的交换,例如,到调度器308(图3)的背压信号,如上文所指出所述调度器将包从VOQ调度到卸载/加速引擎处理器
316,所述处理器如图4中所示为包引擎处理器404。
[0126] 在一个实施例中,包接口402提供多个虚拟内部端口以连接到包引擎处理器404和安全引擎408。使用如上文所述的一个实施例中的端口和VOQ,此内部接口确保针对具有多个遍次的包的极其快速的回转,例如IPSec、通用路由封装协议(GRE)或其它穿隧或桥接帧。
[0127] 非包接口416类似地确保实例子系统400至少与其它组件交换数据,虽然在非包接口的情况下此数据将不呈包的形式。在一个实施例中,包接口402是以太网接口并且非包接口可以包含例如PCIe、SATA和/或USB接口。
[0128] 包引擎处理器404或更一般而言的任何卸载处理器可以是与主CPU 102、104(图1到3)相同类型的处理器或不同类型的处理器。然而,不同于主CPU 102、104,例如包引擎处理器404等卸载处理器被配置为专用或专门的处理器,以用于执行某些类型的功能。在实例子系统400中,这些功能包含包引擎的包处理功能。在此实例中包引擎在软件中实施、存储于存储器410或另一存储器中,所述存储器通过包引擎处理器404执行。包引擎处理器404或其它卸载处理器的类型可以取决于将从主CPU 102、104卸载的特定的功能。一般来说,主CPU 102、104应比卸载处理器具有更大的功率,使得主CPU的卸载并不依赖于额外的硬件,所述额外的硬件几乎与被卸载的硬件(主CPU)一样复杂。当从主CPU到卸载处理器或其它卸载硬件传递任务时这还引起功率节省。
[0129] 在实例子系统400中安全引擎408表示安全功能的硬件实施方案。在一个实施例中,安全引擎408是可配置的但是硬质编码的加密核心。因此实例子系统400说明两个类型的卸载引擎,包含执行软件引擎的一或多个卸载处理器,在此实例中是执行包引擎软件的包引擎处理器404,以及一或多个硬件引擎,即安全引擎408。
[0130] 在一个实施例中,在实例子系统400中存储器410可包含一或多个固态存储器。举例来说,存储器410可以包含静态随机存取存储器(SRAM)的多个块。SA数据库414还应储存在存储器中,但是示出为与图4中的存储器410分开。在一个实施例中,仅有安全引擎408,并且即使实施多个安全引擎那么可能地仅有一个安全引擎具有SA数据库414的完全的直接存取。实例子系统400的其它组件和/或实例子系统在其中实施的系统的组件可能具有到存储器装置或SA数据库414储存的区域的只写存取。
[0131] DMA控制器412表示机载DMA控制器,其向实例子系统400提供对例如图3中以312示出的存储器、SRAM和/或一或多个芯片上存储器等外部存储器的存取。在一个实施例中,DMA控制器412还与Linux驱动器共享,以用于移动安全密钥和数据从而减少时延和处理开销。
[0132] 包引擎是可以定制的以促进专用和/或新封装协议的大功率的且可配置的块。在一个实施例中,包引擎桥接不同协议。举例来说,在一个实施例中,实例网络引擎300(图3)是硬编码的以处理以太网切换,并且包引擎桥接网络引擎与其它非以太网接口之间的流量。在这种情况下包通过包引擎处理器404经由非包接口416接收以用于到以太网的初始处理或转译/转换,并且随后提供到网络引擎。
[0133] 可以由包引擎支持的实例特征包含以下各项中的一者或一者以上∶[0134] ·IPSec包处理(重播、SA改变、封装和解封装)
[0135] ·IP分段重新组装
[0136] ·磁盘块加密/解密
[0137] ·IP穿隧形成和终止
[0138] ·无线桥接,例如,IEEE 802.11与以太网II/IEEE 802.3之间的转换。
[0139] 安全相关任务,例如,磁盘块加密/解密,还涉及安全引擎408。
[0140] 数据处理任务,例如上文提供的实例,因此可以从主CPU 102、104卸载到实例子系统400,由此减小主CPU上用于执行数据处理任务的负载。更多主CPU处理周期随后可用于执行其它任务,例如,较高层应用或服务相关任务。卸载引擎,或更一般而言支持此类引擎的卸载子系统,还可以针对将要卸载的特定数据处理任务进行优化,由此使得那些任务与它们仍然在主CPU 102、104上相比更高效且更快速地执行。
[0141] 在一个实施例中,包引擎可以具有两种类型的用户,包含主CPU 102、104(用于结合安全引擎408的加密支持)以及用于封装、加密、桥接和重新组装支持的网络引擎158、300。这些用户可以使用安全引擎408,同时在一些实施例中预先配置芯片上的多个安全联盟用于每个用户。
[0142] 安全引擎408可以支持各种算法、密码和散列以及安全功能中的任何一个,所述安全功能例如IPSec加密/解密、磁盘块加密/解密、基站加密/解密等等。
[0143] 安全引擎408用于从主CPU 102、104中卸载加密任务。如果纯粹在软件中实施,那么就处理负载而言此类任务应是“昂贵的”。存在可以实施的两个可能的模型,包含其中主CPU 102、104直接控制安全引擎408的一个,以及其中例如包引擎处理器404等卸载处理器控制安全引擎的一个。
[0144] 所述直接控制情况下,在主CPU 102、104上执行的软件应对安全引擎408进行编程以示意性地通过使用控制安全引擎的存储器映射的寄存器执行例如加密/解密等一或多个安全功能。随后主CPU 102、104可以提供存储器指针,所述存储器指针指示将由安全引擎408处理的一或多个包的位置。安全引擎408应加密/解密或者处理包并且随后将指针提供回主CPU 102、104。在此实例中,数据在主CPU 102、104与安全引擎408之间通过存储器指针的交换而共享。还可以提供其它数据共享或交换机构或替代地提供其它数据共享或交换机构以确保安全任务到安全引擎408的卸载。
[0145] 对于“间接”控制实施例,其中卸载处理器,而不是主CPU 102、104,控制安全引擎408,主CPU应指示或以其它方式提供一或多个待处理的包到卸载处理器。举例来说,存储器指针可以提供到包引擎处理器404。卸载处理器随后应对安全引擎408编程并且通过安全引擎408协调包的加密/解密或其它安全处理。这可以涉及提供存储器指针到安全引擎408,并且当安全处理是完整的时从安全引擎中接收存储器指针。随后卸载处理器应指示完成回到主CPU 102、104,方法是例如提供回到主CPU的存储器指针。
[0146] 应了解包引擎处理器404和安全引擎408是卸载或加速引擎的说明性实例。其它实施例可以包含额外和/或不同引擎。
[0147] 举例来说,包引擎处理器404可以是共享处理器,其还用于执行针对其它引擎的软件。类似于安全引擎408,其它卸载或加速引擎可以在专用硬件中实施。
[0148] 链表步行器引擎、缓冲分配器引擎和SAMBA卸载引擎是可以在卸载或加速子系统中实施以进一步促进其功能的其它卸载或加速引擎的说明性实例。这些额外实例引擎未在图4中示出,但是可以与图4的其它组件以与包引擎处理器404和安全引擎408相同的方式互连,不同之处在于如示出用于安全引擎的对SA数据库414的直接完全存取。
[0149] 可以实施链表步行器引擎,例如,作为卸载遍历链表的任务的硬件模块。处理包的软件可能耗费许多时间储存和检索放置于链表数据结构中的包。这些结构变为相当卷绕的并且它可能采用许多存储器读取来追踪储存包的叶节点。链表步行器引擎可以用于从在主CPU 102、104上执行的软件中卸载此处理。替代于在链表结构上进行许多存储器读取,主CPU 102、104可以随后提供链表结构的头部到链表步行器引擎,所述链表步行器引擎将遵循链表结构向下直到叶节点平。一旦完成这步,可以通过软件容易地读取/写入所述包。
[0150] 在一个实施例中,链表步行器引擎可以列表的格式编程,例如,何处寻找指示下一指针的地址和关于列表的结构的其它格式信息的字节。链表步行器引擎可以具有以例如指数所识别的每种格式编程的多个不同格式。当在主CPU 102、104上运行的软件将遍历列表时,它可以向链表步行器引擎提供列表的头部的地址、描述列表的格式的指数以及执行哪个动作的指示。可以执行的动作可以包含,例如:插入一或多个新项到列表的端部,在此情况下主CPU 102、104可以提供指针到含有将插入的项的存储器中的阵列;从列表中移除最后N个项,在此情况下主CPU可以提供指针到链表步行器引擎可以填充的存储器中的空的阵列;和/或其它动作。在一个实施例中链表步行器引擎通过设置中断向主CPU发送完成的信号。
[0151] 可以实施缓冲分配器引擎,例如,作为存储器分配调用的硬件实施方案。当在主CPU 102、104上运行的软件想要将某些内容储存到存储器中时,它可通过使用存储器分配调用请求内核分配存储器。此调用可能耗费许多主CPU周期并且每秒发生多次。在卸载引擎架构中,当软件需要存储器时它可以替代地从缓冲分配器引擎中请求存储器。缓冲分配器引擎可以是追踪系统中的可用存储器并且将所请求的缓冲返回到软件的专门硬件卸载引擎。在一个实施例中,通过缓冲分配器引擎返回到主CPU 102、104的是到已经分配的缓冲(例如,的存储器地址)的指针。
[0152] SAMBA卸载引擎是加速SAMBA协议的实施方案。SAMBA协议允许例如硬盘驱动器等存储装置将在网络上得到存取。所述协议需要网络连接流量被接收且处理成适合于储存到磁盘上的格式。由于网络连接接口上的每个接收到的包必须在SAMBA中得到处理,所以它可能耗费许多CPU周期。SAMBA卸载引擎应允许主CPU 102、104简单地转发去往磁盘的网络流量到SAMBA卸载引擎。SAMBA卸载引擎随后根据SAMBA协议处理流量并且处理全部所得到的文件系统管理,由此通过执行本应通过主CPU执行的数据处理任务减小主CPU 102、104上的处理负载。
[0153] 具体实例-无线保真(WiFi):网络过滤
[0154] 上文中借助于实例参考图1到4描述了处理架构的组件。下文中参考图5到8描述在WiFi应用的情况下提供卸载的实施例的具体实例,所述图是其它实例处理架构的框图。
[0155] 图5中的实例架构500包含5GHz IEEE 802.11ac WiFi模块502。其它实施例可以包含其它类型的WiFi模块。还示出了以太网网络接口卡(NIC)504。在此实例中,这些模块中的二者都耦合到PCIe接口。PCIe接口未在图5中单独地示出,但是在图1和2中示出为118、120、122。
[0156] 在图5中示出了双主CPU架构。为了避免拥塞,主CPU在单个框510中示出。每个主CPU 510支持Linux网络连接协议堆栈512,然而在其它实施例中可以支持其它操作系统。WiFi驱动器514包含下层驱动器516和上层驱动器518。以太网驱动器以520示出,并且主CPU 
510还执行网络接口驱动器522。CPU端口524确保主CPU 510与网络引擎530之间的通信。
[0157] 网络引擎530包含转发引擎532,并且网络引擎530的其它硬编码功能在534处呈现。在实例架构500中,存在每个端口的8个优先级队列,在536处示出。网络引擎530中的一或多个网络接口确保示出为千兆以太网(GE)0、GE 1、GE 2的以太网连接上的通信。在一个实施例中这些连接是通过GMAC接口146、148、150(图1)的。
[0158] 图5中的实例架构500包含呈网络引擎530的形式的硬件卸载引擎或加速器。在图6的实例架构600中示出了其它卸载/加速硬件。安全引擎0、安全引擎1、包引擎0和包引擎1确保额外的卸载和加速。如本文所述,安全引擎处理安全相关功能,并且包引擎处理数据面功能。安全引擎是硬编码的但是可通过在主CPU 501上运行的系统软件配置,并且包引擎包含对应的包引擎处理器602、612;包存储器604、614;以及DMA控制器606、616。
[0159] 如上文所指出,主CPU 510支持Linux网络连接协议堆栈512,并且提供CPU端口524用于与网络引擎530和网络接口驱动器522通信。网络引擎内核模块626控制转发功能,并且实施Linux网络连接协议堆栈512接口与在530处示出的网络引擎硬件之间的接口。网络引擎内核模块626还提供内核挂钩以确保网络引擎530中的卸载和流管理能力,并且控制和管理网络引擎的操作、配置和监测。
[0160] 在实例架构700(图7)中,存在两个WiFi模块,包含2.4GHz IEEE 802.11n模块702和5GHz IEEE 802.11ac模块704,其通过PCIe接口连接到包引擎。包引擎0和包引擎1在图7中主要通过功能块呈现,所述功能块说明在此实施例中通过那些引擎执行的功能。如图所示,包引擎0执行下层WiFi发射(Tx)驱动器714,并且包引擎1执行下层WiFi接收(Rx)驱动器。每个包引擎包含应储存在存储器中的处理器间通信(IPC)邮箱716、726以及例如用于处理穿隧形成和终止的WiFi驱动器隧道模块718、728。一或多个安全模块也可以通过包引擎和/或主CPU 510提供和使用,但是未在图7示出以便避免图式中的拥塞。
[0161] 主CPU 510支持Linux网络连接协议堆栈512,并且包含网络接口驱动器522和网络引擎内核模块626。每个主CPU 510还包含:CPU端口524,以用于与网络引擎530通信;IPC邮箱734;WiFi驱动器736,其包含上层驱动器740和WiFi卸载适配层(WOAL)738,以及WiFi驱动器隧道模块742、744。
[0162] 通过WiFi驱动器隧道模块742、744提供的WiFi驱动器在主CPU 510和包引擎处穿隧、封装802.11(WiFi)帧到可以经由网络引擎530输送到主CPU的802.3(以太网)帧中。在一个实施例中,网络引擎530是基于标准以太网的并且可以理解和转发802.3帧。经由WiFi模块702、704发送和接收的帧可以呈非常不同于802.3帧的802.11帧的形式。
[0163] IPC邮箱734结合包引擎的IPC邮箱716、726操作以提供主CPU 510与包引擎之间的有效通信机构。这在下文中进一步详细描述。在一个实施例中主CPU 510与包引擎之间的IPC机构用于配置、控制和管理功能。在WiFi卸载的本实例中,基于每站的基础,它用于直接控制和更新802.11帧到802.3帧转换且反之亦然。它还可用于例如诊断和性能监测的管理。
[0164] 在WiFi技术中“站”是指连接到存取点(AP)的任何客户端装置。如本文所揭示的处理器架构可以在例如家庭网关等AP中实施。站到站通信将通常通过AP。对于每个站,802.11帧头可能是不同的,并且在一个实施例中包引擎维持用于每个站或用于每个目标MAC地址的转译表。
[0165] 就WiFi驱动器736而言,例如在图5中,在处理WiFi用户数据帧时主CPU利用率为何高的原因是高上下文切换和长存储器存取时延。如图7中所示的WiFi卸载的目标是通过重新定位转发到包引擎和网络引擎530的用户数据流量移除此“瓶颈”。因此,那些数据帧不再通过主CPU路径。在图7中所示的实例卸载设计中,包引擎处理数据接口并且移动用户数据帧进出WiFi模块702、704。因此,包引擎实施如在714、724处呈现的下层驱动器功能和如在740处示出的涉及仍然在主CPU 510上的WiFi驱动器736中的协议管理和控制的上层驱动器功能。WOAL 738确保此卸载,并且在下文中进一步详细描述。
[0166] 网络引擎530继续提供如同转发、帧缓冲和QoS功能的此类特征。下层驱动器714、724主要涉及WiFi模块702、704与在卸载情况(图7)中包引擎之间的数据帧移动,或与在非卸载情况(图5)中主CPU 510之间的数据帧移动。另外,下层驱动器714、724任选地处理其它数据处理任务,例如到用于基于以太网网络引擎530的802.3帧格式的802.11格式转换、帧聚集、速率控制和功率节省。如果提供帧转换,那么包引擎维持用于每个站的转换表,这是由于802.11标头信息从一个站到另一个站发生变化。所述表通过主CPU 510经由IPC邮箱
734、726、716动态地更新,所述主CPU负责每个表与使用控制和管理帧的站的关联。
[0167] 在操作中,WiFi模块702、704支持跨越PCIe或主机接口的两个用户数据帧格式中的任一者,即,802.11帧格式或802.3帧格式。出于说明性目的,考虑其中Linux网络连接协议堆栈512经配置以处于桥接模式的实施例,其中帧是基于目标MAC地址转发的。
[0168] 通过WiFi驱动器隧道模块718、728、742、744提供的WiFi驱动器隧道是内部路径以在包引擎与位于主CPU 510上的WiFi装置驱动器736的上层驱动器740之间发射帧。在一个实施例中这些隧道建立为网络引擎530中的专用流,并且它们具有在802.3帧内部封装802.11帧的能力,所述能力可以通过网络引擎识别。在一个实施例中封装通过WiFi驱动器隧道模块718、728、742、744提供。WiFi驱动器隧道742和744可以是位于CPU端口524上的单独的逻辑接口,每一个具有8个虚拟优先级队列。在此实例实施方案中,CPU端口524支持8个逻辑接口或64个虚拟优先级队列。连接到网络引擎530的每个GE接口还可以具有位于网络接口驱动器522上的8个虚拟优先级队列。
[0169] 考虑接收(Rx)操作,当通过帧类型识别的管理帧通过包引擎1从WiFi模块702、704中的一者中接收时,包引擎通过WiFi驱动器隧道模块728、744之间的WiFi驱动器隧道将此帧直接发送到主CPU 510。所述帧将以透明的方式输送到上层驱动器740。WOAL 738确保数据处理任务的卸载,并且提供上层驱动器740与下层驱动器714、724之间的接口,使得卸载对于上层驱动器是透明的。
[0170] 当通过不同帧类型识别的数据帧通过包引擎1从WiFi模块702、704中的一者中接收时,包引擎中的下层驱动器724将首选检查发射或转发表格以确定在所述表中是否已经存在用于目标MAC地址的项。如果它存在,那么此帧不是用于目标MAC地址的数据流中的第一数据帧,并且它将被输送到网络引擎530以用于转发和处理。如果它并不存在,那么它是用于目标MAC地址的第一数据帧并且它将通过WiFi驱动器隧道被转发到主CPU 510。上层驱动器740将以与图5中的上层驱动器518相同的方式处理帧,包含帧格式从802.11到802.3的转换。随后所述帧被传递到其中将作出转发决策的Linux网络连接协议堆栈512。此决策将提供帧将转发到的出口端口。网络引擎内核模块626将在网络引擎530中形成用于源MAC地址的流项。帧将传递到网络接口驱动器522上,所述网络接口驱动器继而将帧发送到网络引擎530以用于转发。
[0171] 转向发射(Tx)操作,当帧在网络引擎530中的以太网接口中的一者上接收并且针对其目标MAC地址未发现流项匹配时,它将随后被转发至位于主CPU 510上的网络接口驱动器522。网络接口驱动器522将帧传递到Linux网络连接协议堆栈512以用于转发决策。如果用于此帧的出口端口是WiFi接口,那么802.3格式的帧将被传递到WiFi装置驱动器736中的上层驱动器740上以用于进行处理。流项随后或基本上同时在网络引擎530中通过网络引擎内核模块626形成使得承载相同目标MAC地址的随后的帧将从网络引擎530直接转发到包引擎0而无需涉及主CPU 510,由此提供卸载效果。当帧通过网络引擎530直接转发到WiFi下层装置驱动器714时在WiFi下层装置驱动器714处的基本操作是将802.3帧转换成802.11帧,以及其它处理功能。所述帧将穿过WiFi驱动器隧道被发送到包引擎0。随后,或基本上同时地,WOAL 736将发送配置消息到包引擎0,使得项将在通过目标MAC地址编索引的发射表中形成。此项将允许承载目标MAC地址的802.3帧转换成802.11帧,使得它可以直接被发射到适当的WiFi模块702、704。
[0172] 图8中的实例架构800大体类似于图7中的实例架构700,不同之处在于包引擎0和包引擎1都处理发射和接收操作。下层驱动器814、824、IPC邮箱816、826以及WiFi驱动器隧道模块818、828、842、844因此支持双向通信。IPC邮箱816、826之间的相互作用也略微地不同于在实例架构800中,因为在此实例中IPC邮箱不必直接彼此相互作用,其中每个包引擎处理发射和接收这两种操作。图7中的实例架构700与图8中的实例架构800之间的一个差异在于如果WiFi模块702、704的处理功率要求是不对称的,那么形成器允许负载平衡。然而,在图8中的实例架构800中将WiFi模块702、704这两者互连到包引擎0和1这两者也将是可能的。
[0173] 图9中的实例处理架构900涉及网络过滤。在此实施例中,涉及网络过滤的数据处理任务是从主CPU 510卸载到网络引擎930的,所述网络引擎包含散列分类器908、流量管理器906和转发引擎932。网络引擎930可以与在其它实施例中基本上相同的方式实施,但是在图9中不同地标记以说明在一些实施例中除转发任务之外,它还提供网络过滤任务的卸载。网络引擎930与互联网902通信。协议管理或控制任务仍然位于主CPU 510上,并且在图9中示出为统一资源定位符(URL)处理910。在此实例中URL处理910呈由主CPU 510执行的软件的形式。本地URL数据库912储存规定数据流量如何经过滤的过滤控制信息。在一个实施例中,本地URL数据库912可以储存“白名单”或规定所准许的数据流量的准许流信息,在此情况下非准许的流将被丢弃或以其它方式经过滤。在所示的实例中本地URL数据库912由从可以安全服务器904中更新的URL数据库填入。这些更新可以是日常基础的、一些其它自动调度的和/或请求驱动的。在图9中还示出了网络引擎内核模块914。
[0174] 在一个实施例中散列分类器908、转发引擎932和流量管理器906是基于硬件的,并且例如在可配置的但是硬编码的硬件中实施。在实例处理架构900中散列分类器908基于通过网络引擎驱动器914的白名单配置识别FITTP流。如果超文本传输协议(FITTP)流(1)未被散列分类器908识别(这应该是例如针对流中的新包的情况),那么流被转发(2)到主CPU以进行识别。作为URL处理的一部分在910处,应查询(3)、(4)本地URL数据库912和/或可以服务安全服务器904。如果所述流是准许的流(5),那么散列分类器908的散列表经配置(6)用于通过网络引擎内核模块914的准许的流,或者URL处理910发送(5-拒绝)具有针对拒绝流的TCP会话重置的FITTP答复,或替代地,URL重新定向消息(未在图中示出)。此FITTP答复或重新定向通过网络引擎930返回到请求用户系统。
[0175] 通过散列分类器908识别的流由网络引擎930处理而无需主CPU 510的参与,由此在来自主CPU的初始识别之后卸载数据处理。
[0176] 图5到9中的WiFi和网络过滤实例说明确保从主CPU 510的实质上数据处理任务的卸载的第一包处理的一种形式。虽然当流未由卸载引擎识别时涉及主CPU 510,但是用于流的数据处理在流已经最初由在主CPU 510上执行的软件识别之后可以被卸载。管理或控制任务仍然位于主CPU 510上,但是数据处理任务卸载到卸载引擎。在图7和8的WiFi的实例中,主CPU 510仍然处理上层WiFi协议管理或控制任务,并且因此卸载并不改变协议如何操作或需要WiFi模块702、704中的任何改变。类似地,在图9中的网络过滤实例中,URL处理910驻存在主CPU 510上,并且过滤卸载所述网络引擎930中的散列分类器908并不影响HTTP和TCP操作。用于HTTP和TCP的协议管理或控制任务通过主CPU 510处理,并且数据处理卸载到网络引擎930。
[0177] 软件分区/拆分
[0178] 本文所揭示的处理架构确保任务从一或多个主CPU卸载到一或多个卸载或加速引擎。举例来说,例如外围装置驱动器等软件可涉及协议管理或控制任务和数据处理任务。在一个实施例中,管理或控制任务仍然位于主CPU上,使得卸载并不改变协议或例如WiFi模块等接口装置操作的方式以及下层数据处理任务卸载的方式。此类软件分区或拆分需要识别哪些件软件或哪个任务对重新定位到卸载引擎有意义以及那件软件或任务应该驻留在主CPU上。在一个实施例中,处理大多数数据流量并且因此在通用应用程序处理器上效率最低的软件驱动器的件可以重写、修改或以其它方式传送到卸载引擎并且开拓将仍然用于由主CPU执行的软件。
[0179] 图10说明分区装置驱动器的实例。实例分区装置驱动器1000涉及如图7中所示分区的WiFi装置驱动器,其中上层驱动器740保留在主CPU 510上并且下层驱动器814、824卸载到包引擎。此卸载通过WOAL 738启用。WiFi驱动器隧道模块742、744和IPC邮箱734示出为在图7中与WOAL 738分开,但是在图10中示出为WOAL的一部分,这是因为WOAL与这些组件相互作用以提供下层驱动器814、824与上层驱动器740之间的适配层或接口。在实例1000中,WOAL 738是应用软件编程接口(API)。此API的目的是允许下层驱动器与上层驱动器分离使得它们中的任一者中的改变将对另一者具有极小影响或不具影响。
[0180] 在一个实施例中,上层驱动器740执行802.11协议管理任务并且提供装置驱动器接口到Linux网络连接堆栈512(图7、8),并且下层驱动器814、824通过在实例中示出的PCIe接口和PCIe控制器驱动器914处理到外围装置(即WiFi模块702、704(图7、8))和来自外围装置的实际数据移动。在此实例中,在1002处通过帧转换器的例如802.11/802.3帧转换、在1004处通过帧集合器的帧聚集、在1006处通过速率控制器的速率控制以及在1008处通过功率控制器用于功率节省特征的功率管理等任务在下层驱动器814、824中卸载。
[0181] 在一个实施例中WiFi模块702、704与下层驱动器714、724、814、824之间的数据的移动经由包环状结构通过DMA操作执行。包环状结构含有包描述词,所述包描述词通过读取指针和写入指针描述储存在包存储器中的包。每个包描述符1010、1012具有包信息,例如,用于包和包长度的存储器位置。当包准备好从WiFi模块702、704传输到包引擎时,中断信号被发送到包引擎。包引擎随后起始在接收包环中来自读取指针的传输。存在用于从包引擎到WiFi模块702、704的传输的类似包环。
[0182] 在上层驱动器740与下层驱动器814、824之间,WOAL 738提供“垫片”或接口层以确保卸载能力处于对上层驱动器透明的方式。WOAL 738经由IPC邮箱734控制卸载引擎(即,在此实例中为包引擎)并且与卸载引擎通信,并且还提供WiFi驱动器隧道用于透传数据输送。下层驱动器814、824可以重写或以其它方式修改用于与通过WOAL738提供的卸载API的兼容性,所述WOAL继而与上层驱动器740介接。卸载可以对上层驱动器740完全透明,方法是使WOAL 738提供到上层驱动器的符合接口定义或规格的接口,通过所述接口仍然位于主CPU 
510(图7、8)上的例程或功能与将被卸载的例程或功能相互作用。举例来说,WOAL 738可以适于接纳来自上层驱动器740中的为驱动器“原生”格式的功能或例程呼叫,并且同样以原生格式将结果返回到上层驱动器。用于实施卸载任务或功能的原生格式与其它格式之间的转译可以随后通过WOAL 738处理。WiFi驱动器隧道模块742、744表示这种类型的特征的实例,其允许WiFi帧在包引擎与主CPU 510之间通过网络引擎530(图7)传送。
[0183] 图10涉及用于从一或多个主CPU到卸载处理器和/或其它硬件的卸载功能的WiFi装置驱动器软件拆分或分区。类似的软件拆分或分区可以在图8中的实例处理架构800中使用。用于其它类型的装置和/或甚至其它类型的软件的驱动器可以在其它实施例中拆分或分区以卸载某些任务。
[0184] 举例来说,在图9中的实例处理架构900中,网络过滤软件在主CPU 510与网络引擎930之间拆分。处理协议管理或控制任务的URL处理保留在主CPU上。数据处理任务,在这种情况下是过滤,卸载到网络引擎930。
[0185] 更一般地考虑软件拆分,来自主CPU的卸载任务的一个目标可能是重新定位在通用处理器上没有效率的任务到功率不太大的但是专门配置的处理器或其它卸载硬件。举例来说,这种类型的方法可以由主CPU处理瓶颈和/或高主CPU利用率驱动。
[0186] 在开发卸载策略中,还可能希望的是不改变协议,因为这样做将形成连接到处理架构的装置中的额外处理负载和/或改变。考虑WiFi卸载作为一个实例,可能的是改变WiFi模块702、704(图7、8),使得在数据到达PCIe接口之前在“前端”处执行一些任务。然而,此方法显著影响WiFi装置设计。传统地,WiFi装置不是智能的,因为处理智能驻存一个处理系统中的其它地方。将智能重新定位到WiFi装置上本身需要装置设计的相当大的转换并且还显著地影响了WiFi协议。
[0187] 在一个实施例中可以进行装置驱动器软件和/或其它类型的软件的分析以识别下层(例如,层1或层2)数据处理瓶颈,其涉及在一个实施例中唯一单层处的数据处理。与数据处理任务相比协议管理或控制任务倾向于是不太处理器密集的,并且一般而言较不频繁的执行,并且因此协议管理或控制任务可以是仍然位于主CPU上的良好的候选。一旦识别数据处理任务用于卸载,则用于执行那些任务的软件可以重写或以其它方式修改以在卸载硬件上运行。在一些实施例中,此类任务可以硬编码成模拟软件任务的硬件。就速度而言卸载任务的硬编码可以提供其它益处。
[0188] 装置驱动器例如可在特定类型的数据上执行特定任务。因此,对于在本文中通常称作“流”的输入的某一类型或模式,将总是执行特定任务或任务的组。此类型的动作可以是软编码或硬编码到卸载引擎中的。在一个实施例中,用于新数据流的第一包提供到主CPU以用于基于标头处理或其它协议管理处理进行识别。在主CPU上执行的软件可以随后更新卸载引擎表或者提供识别信息到卸载引擎,所述卸载引擎可以随后识别相同流中的其它包并且执行相同数据处理任务而无需涉及主CPU。在此实例中此类通过主CPU处理的“第一包”提供用于集中的协议管理处理,同时仍然启用将被卸载的数据处理任务。第一包可以在一个实施例中扩展以包含多个包直至用于卸载的流可以在主CPU上被识别。
[0189] 存储器子系统
[0190] 拆分或分区软件功能引发主CPU与卸载处理器之间的通信开销。高速缓存一致性硬件提供于一些实施例中并且允许跨越处理器之间的系统总线的交易从每个处理器的存储器子系统的度成为一致的。这减少开销花费定和解锁资源的量并且因此允许处理器更加迅速地通信。高速缓存一致性实施方式可以提供用于均质主CPU/卸载处理器架构(即,主CPU和卸载处理器是相同类型的)或异质处理器架构架构
[0191] 高速缓存一致性允许主CPU使用存储器和高速缓存与卸载引擎通信而无需带来必须等待例如自旋锁或邮箱等消息传递机构的开销。这引起较少的浪费的主CPU时钟循环并且因此最小化功率耗散并且最大化性能。
[0192] 在一个实施例中,高速缓存一致性通过经由处理器高速缓存一致性端口给予卸载引擎对主CPU L1和L2高速缓存的存取而实施。当卸载引擎经配置以使用高速缓存一致性存取时,它们通过经过主处理器L1或L2高速缓存而从DDR或SRAM存储器位置中读取并且写入到DDR或SRAM存储器位置。
[0193] 举例来说,主CPU可向卸载引擎传递指示储存的包的位置的存储器指针。在非高速缓存一致性配置中,卸载引擎将随后直接从存储器中读取包并且对包进行处理。随后它将所述包写回到存储器,由于相对于芯片上处理器的速度的存储器的缓慢速度这可能耗费较长时间。如果主CPU尝试在卸载引擎工作的时间期间读取相同包数据,那么它将获得不正确的数据。为了避免这样,主CPU必须替代地使用软件周期以轮询或者等待卸载引擎指示写入到存储器的完成,并且随后前进到从存储器中读取回包数据。
[0194] 在确保一致性的系统中,卸载引擎将通过主CPU的L1/L2高速缓存结构读取包。这将使得主CPU从存储器中读取包数据并且将包数据曝露于其高速缓存。当卸载引擎完成修改包数据时,将包数据写回到主CPU的L1/L2高速缓存结构。这允许CPU立即存取修改过的数据而无需等待它写回到存储器。
[0195] 本文所揭示的处理架构可以高速缓存一致性模式或非高速缓存一致性模式运行。对于非高速缓存一致性模式,可以提供IPC邮箱以促进卸载引擎与主CPU之间的通信。例如图7和8中所示的那些邮箱允许以相对低的CPU开销进行可靠的消息传递。当卸载引擎已经完成任务时,它可以将指示完成的消息放置到邮箱中以用于主CPU。在一个实施例中,这将造成将对主CPU生成中断。作为中断处理例程的一部分,主CPU可以随后读取消息并且被通知任务完成。这保持主CPU与卸载引擎彼此同步。
[0196] 柔性的I/O
[0197] 在一个实施例中,柔性且动态地可控制的互连件,例如,在图2中以272示出启用处理系统中的任何处理器或卸载/加速引擎以控制系统中的任何资源。这允许软件分配哪些处理器或硬件将控制哪些I/O处于运行时间。举例来说,卸载处理器可以在它这样做有意义时控制高带宽SERDES I/O,例如,PCIe,例如,当特定PCIe接口连接到WiFi模块并且用于WiFi的数据处理任务将被卸载时。
[0198] 一些实施例还可或替代地提供用于相同引脚或端口上方的接口的多路复用。I/O中的此类型的柔性借助于图11中的实例示出,图11是说明低速接口的框图。如图11中所示,例如PCM接口132、闪存接口142和LCD接口130等低速接口可以通过GPIO功能多路复用以用于GPIO接口138。这允许软件将I/O引脚动态地分配到功能。
[0199] 图12是说明高速接口和类似地多路复用特征的框图。实例接口布置1200示出了基于柔性I/O的SerDes。如图1中在118、120、122处示出,PCIe和SATA接口可以在相同I/O上共享,即使它们是两个不同的协议也是如此。这可以在接口布置1200中实施,所述接口布置包含SerDes 1202、多路复用器1204和PCIe以及SATA接口1206、1208。系统软件可以确定在芯片运行的同时SerDes I/O是否应该充当PCIe或SATA接口,以及随后将它配置到该协议。其它高速接口可以是以类似方式多路复用的,并且USB接口1210在图12中示出为一个此类接口的一个实例。
[0200] 实例应用
[0201] 如本文所揭示的处理架构可以在各种应用中的任何一个中实施。
[0202] 在服务提供商视频网关中,例如,PCIe集成式接口118、120、122(图1)可以用于提供两个独立WiFi连接和额外高速多通道转码/解码以促进完整的视频解决方案。在一个实施例中USB端口126、128中的一者可以用于存取处理架构,留下另一者可用于主机或装置用户连接以用于打印机和磁盘附接存储装置。所述集成式SATA端口124和/或一或多个PCIe/SATA接口118、120、122可以在这种类型的应用中使用以用于个人录像机(PVR)和/或网络连接存储(NAS)功能。
[0203] 处理器架构中的可缩放接口和性能可以支持宽范围的花费和媒体服务器模型。例如,图1中的实例架构100支持在118、120、122、124处的多达四个SATA端口,这些端口中的任一者或全部可以用于实施广泛范围的NAS解决方案。在一个实施例中LCD接口130直接支持相框功能,并且还可以通过高清晰多媒体接口(HDMI)转换器连接到面板,例如,从而以较低花费提供中间分辨率显示器输出。
[0204] 在实施路由器/VPN集中器中,双USB端口126、128中的一者可以装置模式配置以允许USB存储装置和其它USB装置连接。在USB装置模式下,USB端口被视为通过PC或其它连接系统的USB大容量存储装置。在118、120、122、124处的SATA端口还可以用于外部存储器。VPN应用还将利用由安全引擎160提供的加密能力。
[0205] 实例架构100还可以是可用于通过其用于高相机计数视频转换器的3个PCIe接口118、120、122提供用于安全驻地设备的低成本解决方案。安全引擎160中的机载加密能力允许经编码视频的安全储存。主CPU 102、104的处理功率可以支持多个相机转码而无需额外的硬件支持。如果视频俘获装置支持编码,那么实例架构100可以通过安全引擎160刚好提供储存数据的加密和解密。
[0206] 图13是说明实例多服务系统的框图。实例多服务系统1300包含微微(pico)端1302,其可以表示家庭或中小企业(SME)设备。本文所揭示的处理架构可以在微微云端1302中实施以支持图13中所示的各种服务中的任一者或全部。超微型小区1304可以提供在例如长期演进(LTE)无线连接上。一或多个USB装置1306通过USB连接而连接到微微云端1302。
NAT服务可以通过一或多个SATA连接磁盘储存器1308启用。在1310处的一或多个WiFi装置可以通过如上文具体论述的PCIe连接而连接到微微云端1302。在1312处的TV服务通过一或多个传输流(TS)连接而启用。在实例多服务系统1300中,LAN服务1314可以通过一或多个以太网连接提供。在1316处,例如出于家庭安全目的可以提供深度包检测(DPI)模块。DPI模块
1316可以是可以连接到在微微云端1302中的处理架构中的网络引擎的单独的硬件模块。电话服务可以在一或多个PCM连接上得到支持,如在1318处所示,并且还可以提供到互联网
1320的WAN连接。
[0207] 考虑DPI模块1316,替代于仅查看L2、L3或L4标头来决定是否准许/丢弃/路由包,此模块可以非常深入地查看到例如包的L7内容中并且随后决定做何种动作。DPI模块1316可以采用规定寻找何者并且采用何种动作的“规则”,并且例如可以用于到包中查看并且寻找病毒。感染的包可以随后被识别并且丢弃。这可以是在云端环境中所关注的以防止在任何“边缘”处进入云端网络之前的恶意活动。
[0208] 在一个实施例中,微微云端1302通过包含处理架构和多个接口的网关提供。图14是说明实例网关的框图。
[0209] 实例网关1400包含:供电组件,例如,调节器1404,在此实例中其耦合到110V电源;以及电池1406。电池1406可以经实施以提供例如用于需要功率来进行操作的电话的“生命线”保护。如果实例网关1400用于家庭电话服务,那么在电源故障的情况下电池1406可以至少临时地维持电话服务。
[0210] 根据本文所提供的教示的处理架构1402通过其各种接口耦合到在此实例中呈DRAM 1404和快闪存储器1422形式的存储器。WiFi无线电1406、1408通过集成式PCIe接口连接到处理架构1402。在1410、1412处示出USB端口以用于连接到外部USB装置。网关还可包含磁盘储存器,例如,连接到处理架构1402的SATA接口的硬盘驱动器1414。在处理架构1402中,电话接口1416,例如,电话插口,可以连接到一或多个集成式PCM接口,和/或例如在IP承载语音(VoIP)电话的情况下的其它接口。
[0211] 启用视频的网关可以包含连接到处理架构1402中的传输流接口的一或多个TV调谐器1418。以太网端口在1420处示出,并且可以用于提供互联网连接,以用于一或多个独立的电脑和/或网络连接的电脑。
[0212] 所描述的内容仅是本发明的实施例的原理的应用的说明。在不脱离本发明的范围的情况下,可由所属领域的技术人员实施其它布置和方法。
[0213] 举例来说,附图仅意图用于说明性目的。其它实施例可以包含额外的、较少的组件和/或以类似或不同布置互连的额外的组件。主CPU 102、104(图1)中的每一个可以包含具有例如其自身的数据高速缓存和指令高速缓存的数字信号处理器(DSP)。在一个实施例中,这些高速缓存各自是32kB,然而还涵盖了不同数目和/或尺寸的高速缓存。
[0214] 另外,虽然主要在方法和系统的情况下进行了描述,但是还涵盖了本发明的其它实施方式,例如如储存在计算机上可读媒体上的指令。
[0215] 本文中的单数或复数形式的特征并非意图将实施例限制于任何数目的实例或组件。举例来说,本文中所揭示的处理架构不必结合多个主CPU实施。
[0216] 还应注意包是可以如本文所揭示的处理的数据的块的说明性的且非限制性的实例。小区、帧和/或其它数据块可以与包相同或类似方式处理。
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈