网络引擎530中的一或多个网络接口确保示出为千兆以太网(GE)0、GE UGE 2的以太网连接上的通信。在一个实施例中这些连接是通过GMAC接口 146、148、150 (图1)的。
[0158]图5中的实例架构500包含呈网络引擎530的形式的硬件卸载引擎或加速器。在图6的实例架构600中示出了其它卸载/加速硬件。安全引擎0、安全引擎1、包引擎O和包引擎I确保额外的卸载和加速。如本文所述，安全引擎处理安全相关功能，并且包引擎处理数据面功能。安全引擎是硬编码的但是可通过在主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.1ln模块702和5GHz IEEE 802.1lac模块704，其通过PCIe接口连接到包引擎。包引擎O和包引擎I在图7中主要通过功能块呈现，所述功能块说明在此实施例中通过那些引擎执行的功能。如图所示，包引擎O执行下层WiFi发射(Tx)驱动器714，并且包引擎I执行下层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 ；ffiFi驱动器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)操作，当通过帧类型识别的管理帧通过包引擎I从WiFi模块702、704中的一者中接收时，包引擎通过WiFi驱动器隧道模块728、744之间的WiFi驱动器隧道将此帧直接发送到主CPU 510。所述帧将以透明的方式输送到上层驱动器740。WOAL 738确保数据处理任务的卸载，并且提供上层驱动器740与下层驱动器714、724之间的接口，使得卸载对于上层驱动器是透明的。
[0170]当通过不同帧类型识别的数据帧通过包引擎I从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直接转发到包引擎O而无需涉及主CPU 510，由此提供卸载效果。当帧通过网络引擎530直接转发到WiFi下层装置驱动器714时在WiFi下层装置驱动器714处的基本操作是将802.3帧转换成802.11帧，以及其它处理功能。所述帧将穿过WiFi驱动器隧道被发送到包引擎
O。随后，或基本上同时地，WOAL 736将发送配置消息到包引擎0，使得项将在通过目标MAC地址编索引的发射表中形成。此项将允许承载目标MAC地址的802.3帧转换成802.11帧，使得它可以直接被发射到适当的WiFi模块702、704。
[0172]图8中的实例架构800大体类似于图7中的实例架构700，不同之处在于包引擎O和包引擎I都处理发射和接收操作。下层驱动器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这两者互连到包引擎O和I这两者也将是可能的。
[0173]图9中的实例处理架构900涉及网络过滤。在此实施例中，涉及网络过滤的数据处理任务是从主CPU 510卸载到网络引擎930的，所述网络引擎包含散列分类器908、流量管理器906和转发引擎932。网络引擎930可以与在其它实施例中基本上相同的方式实施，但是在图9中不同地标记以说明在一些实施例中除转发任务之外，它还提供网络过滤任务的卸载。网络引擎930与互联网902通信。协议管理或控制任务仍然位于主CPU 510上，并且在图9中示出为统一资源定位符(URL)处理910。在此实例中URL处理910呈由主CPU510执行的软件的形式。本地URL数据库912储存规定数据流量如何经过滤的过滤控制信息。在一个实施例中，本地URL数据库912可以储存“白名单”或规定所准许的数据流量的准许流信息，在此情况下非准许的流将被丢弃或以其它方式经过滤。在所示的实例中本地URL数据库912由从可以安全服务器904中更新的URL数据库填入。这些更新可以是日常基础的、一些其它自动调度的和/或请求驱动的。在图9中还示出了网络引擎内核模块914。
[0174]在一个实施例中散列分类器908、转发引擎932和流量管理器906是基于硬件的，并且例如在可配置的但是硬编码的硬件中实施。在实例处理架构900中散列分类器908基于通过网络引擎驱动器914的白名单配置识别FITTP流。如果超文本传输协议(FITTP)流
(I)未被散列分类器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上。在一个实施例中，处理大多数数据