HK40017505A - Secure in-line received network packet processing - Google Patents

Description

Secure online received network packet processing

Technical Field

The Open Systems Interconnection (OSI) reference model defines seven network protocol layers (L1-L7) for communication over a transmission medium. The upper layers (L4-L7) represent end-to-end communications and the lower layers (L1-L3) represent local communications.

Background

Network application aware system operations process, filter and switch a series of L3 to L7 network protocol layers, e.g., L7 network protocol layers such as HyperText transfer protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), and L4 network protocol layers such as Transmission Control Protocol (TCP). in addition to processing the network protocol layers, a network application aware system needs to protect these protocols by L4-L7 network protocol layers including firewalls, Virtual Private Networks (VPNs), Secure Sockets Layer (SSL), Intrusion Detection Systems (IDS), Internet protocol Security (IPsec), anti-virus (AV) and anti-spam functions at the line speed while utilizing access and content based security Data integrity, data source authentication, data encryption, and replay protection.

In today's internet world, improving the efficiency and security of network operations remains a final goal of internet users. Access control, traffic engineering, intrusion detection, and many other network services require distinguishing packets based on multiple fields of the packet header, which is referred to as packet classification.

Typical network processors schedule and queue work, such as packet processing operations for upper layer network protocols, and allow processing of upper layer network protocols (e.g., transport and application layers) in received packets before forwarding the packets to connected devices. Network processors typically perform functions including packet filtering, queue management and priority, quality of service execution, and access control. By employing functions specific to processing packet data, the network processor may optimize the interface of the network device.

Disclosure of Invention

Example embodiments include a network services processor configured to transmit and receive packets over a secure communication channel, such as an IPsec channel. In one embodiment, the network services processor may include a network parser, a network interface controller, a cryptographic engine, and a packet processor. The network parser may be configured to determine an encryption status from a packet header of the packet, where the encryption status indicates whether the packet is a candidate for decryption. The network interface controller may be configured to create a work queue entry indicating that packet processing is required for the packet. The controller may also selectively forward decryption commands based on the encryption status. The cryptographic unit operating as a decryption engine may be configured to decrypt the packet in response to a decryption command and generate a decrypted packet. The packet processor may be configured to process the packet based on the work queue entry, wherein the packet processor accesses the packet or the decrypted packet according to the encryption state.

Additional embodiments may include a network processor including a packet processor, a cryptographic unit, and a network interface controller. The packet processor may be configured to generate a packet and selectively generate encryption instructions for the packet. In response to the encryption instruction, the cryptographic unit operating as an encryption engine may be configured to: 1) encrypt the packet to generate an encrypted packet, and 2) forward the encrypted packet and send the descriptor. The network interface controller may be configured to construct an outgoing packet from the encrypted packet based on the transmit descriptor received from the encryption engine.

Drawings

The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.

FIG. 1 is a block diagram illustrating a network services processor in which embodiments of the invention may be implemented.

FIG. 2 is a block diagram of the networking and input-output portion of the network services processor of FIG. 1.

Fig. 3 is a block diagram of components that operate to transmit packets in one embodiment.

Fig. 4 is a flow diagram of packet transmission operations in one embodiment.

Fig. 5 is a block diagram of components that operate to receive packets in one embodiment.

Fig. 6 is a flow diagram of packet reception operations in one embodiment.

7A-7C illustrate data entries implemented in example embodiments.

Fig. 8 is a block diagram of components that operate to receive packets in further embodiments.

Detailed Description

The following is a description of example embodiments.

Fig. 1 is a block diagram illustrating a network services processor 100. The network services processor 100 may process the open systems interconnection network L2-L7 layer protocol encapsulated in received packets. As is well known to those skilled in the art, the Open Systems Interconnection (OSI) reference model defines seven network protocol layers (L1-L7). The physical layer (L1) represents the actual interface, both electrical and physical, that connects the device to the transmission medium. The data link layer (L2) performs data framing. The network layer (L3) formats the data into packets. The transport layer (L4) handles end-to-end transport. The session layer (L5) manages communication between devices, e.g., whether the communication is half duplex or full duplex. The presentation layer (L6) manages data formatting and presentation, e.g., syntax, control codes, special graphics and character sets. The application layer (L7) allows communication between users, such as file transfers and e-mail.

Network services processor 100 may schedule and queue work (packet processing operations) for upper network protocols (e.g., L4-L7) and allow processing of the upper network protocols in the received packet to forward the packet at wire-speed. Line speed is the rate of data transmission of the network over which data is transmitted and received. By processing the protocol to forward packets at wire speed, the network services processor does not slow down the network data transmission rate.

The interface unit 122 receives packets for processing. The interface unit 122 performs preprocessing of the received packet by checking various fields in a network protocol header (e.g., L2, L3, and L4 headers) included in the received packet, and may perform checksum checking on a TCP/User Datagram Protocol (UDP) (L3 network protocol). Interface unit 122 may receive packets via a plurality of network interface protocols, such as ethernet and peripheral component interconnect express (PCIe). In further embodiments, interface unit 122 may be configured to receive packets from multiple X Attachment Unit Interfaces (XAUI), reduced X attachment unit interfaces (RXAAUI), Serial Gigabit Media Independent Interfaces (SGMII), 40GBASE-R, 50GBASE-R, and/or 100 GBASE-R. The interface unit 122 may also prepare and transmit outgoing packets via one or more of the interfaces described above.

The interface unit 122 may then write the packet data to a buffer in the last level cache and controller (LLC)130 or the external DRAM 108. The packet data may be written to the buffer in a format that facilitates higher layer software executing in the at least one ARM processor core 120. Thus, further processing of higher layer network protocols is facilitated.

The network services processor 100 may also include one or more special purpose coprocessors. When included, these coprocessors offload some of the processing from core 120, thereby enabling the network services processor to achieve high throughput packet processing. For example, a compression/decompression coprocessor 132 dedicated to performing compression/decompression of received packets is provided.

I/O bridge 138 is configured to manage overall protocols and arbitration and provide consistent I/O allocation using I/O bus 142. I/O bridge 138 may include buffer queues for storing information to be transferred between Coherent Memory Interconnect (CMI)144, I/O bus 142, and interface unit 122. I/O bridge 138 may include a plurality of individual bridges over which communication and arbitration may be distributed.

Other I/O interfaces (MIO)116 may include auxiliary interfaces such as general purpose I/O (GPIO), flash, IEEE 802 two-wire management data I/O interface (MDIO), Serial Management Interface (SMI), universal asynchronous receiver/transmitter (UART), two-wire serial interface (TWSI), and other serial interfaces.

A scheduling/Synchronization and Sequencing (SSO) module 148 queues and schedules the work of the processor cores 120. Work is queued by adding a work queue entry to the queue. For example, interface unit 122 adds a work queue entry for each packet arrival. The timer unit 150 is used to schedule the operation of the processor core 120.

The processor core 120 requests work from the SSO module 148. The SSO module 148 selects (e.g., schedules) a work for one of the processor cores 120 and returns a pointer to a work queue entry describing the work to the processor core 120.

The processor core 120, in turn, includes an instruction cache 152, a level 1 data cache 154. In one embodiment, the network services processor 100 includes 24 ARM processor cores 120. In some embodiments, each ARM processor core 120 may be an implementation of the armv8.2 64-bit architecture, and may be compatible with the armv8.2 software ecosystem and include hardware floating point numbers, SIMDs, and MMU support. In such embodiments, consistent with the ARMv8.2 architecture, the core 120 may contain complete hardware support for virtualization. The guest operating system can thus run at the ARM-defined user and operating system privilege levels, while the hypervisor software can run at a separate higher privilege level. The core 120 may also support a secure state in which software may run at three different privilege levels, while hardware provides isolation from non-secure states.

The last level cache and controller (LLC)130 and the external DRAM108 are shared by all processor cores 120 and the I/O coprocessor device. Each processor core 120 is coupled to the LLC 130 through the CMI 144. CMI 144 is a communication channel for all memory and I/O transactions between processor cores 120, I/O bridge 138, and LLC 130. In one embodiment, the CMI 144 may be extended to multiple (e.g., 24) processor cores 120, supporting a fully coherent level 1 data cache 154 with write-through (writethrough) mode. CMI 144 may be highly buffered with the ability to prioritize I/O.

The controller of LLC 130 maintains memory reference coherency. Whether the block is stored in LLC 130, external DRAM108, or "on the fly," it returns the most recent copy of the block for each fill request. The plurality of DRAM controllers 133 support the external DRAM108 and may support a preferred protocol, such as the DDR4 protocol.

After the packet has been processed by the processor core 120, the interface unit 122 reads the packet data from the LLC 130, DRAM108, performs L4 network protocol post processing (e.g., generates a TCP/UCP checksum), forwards the packet through the interface unit 122, and releases the LLC 130/DRAM 108 used by the packet. DRAM controller 133 manages ongoing transactions (loads/stores) to/from DRAM 108.

A Resource Virtualization Unit (RVU)162 may enable software to map various Local Function (LF) resources in various modules into several Physical Functions (PFs) and Virtual Functions (VFs). This makes the multi-element software driver compatible with Linux, Windows, and DPDK. An A Bose Chaudhuri Hocquenghem unit (BCH)146 may implement a BCH cyclic error correction code that is capable of correcting many errors within a data block. The BCH 146 may accelerate both parity generation and error correction functions.

Management module 126 may include various units for managing the operation of network services processor 100. For example, the management module 126 may include a temperature sensor, a power serial bus master interface for determining current performance and energy consumption, and a memory diagnostic controller for detecting and reporting memory errors. The module 126 may further include a control processor, such as a system control processor for power management and other secure chip management tasks, and a module control processor for module management and other non-secure chip management tasks.

Fig. 2 is a more detailed block diagram of the interface unit 122. Transceiver module 290 transmits and receives signals according to one or more communication protocols, such as PCIe, ethernet, and SATA. Interface modules 285, including PCI express interface units (PEM0-PEM3), SATA interface units (SATA), and ethernet I/O controllers (CGX0-CGX2), process received and outgoing signals according to their respective protocols. A Network Controller Sideband Interface (NCSI) unit 276 provides an interface and protocol controller for NCSI bus 277, which provides network packet data to/from CGX interface module 285.

Network interface unit (NIX)210 provides a controller and a Direct Memory Access (DMA) engine to process and move network packets. NIX210 transmits packets to and receives packets from the aforementioned interface 285, and communicates with SSO module 148 to schedule the operation of core 120 for further processing of the packets. The NIX may also communicate with the core 120 to work in place of SSO148 forwarding and may receive packets from the core 120 for transmission. Core 120 shown in figure 1 may include a processor such as ARM processor 220 shown in figure 2. The NIX may include a transmit subunit (NIX-TX) and a receive subunit (NIX-RX), and a loop module (LBK)272 enables packets transmitted by the NIX-TX to be looped back and received by the NIX-RX.

The NIX210 operates with multiple coprocessors. In particular, a network parser CAM unit (NPC)212 parses network packets received by or transmitted from the NIX. A network pool allocator unit (NPA)214 may allocate and release pointers for packets, work queue entries, send descriptor buffers, and may support integration with virtualization schemes. As described above, SSO148 schedules work queue entries for NIX packets. The cryptographic accelerator unit (CPT)230 optionally decrypts internet protocol security (IPsec) packets received by the NIX210 and may encrypt data of outgoing packets. The data cache (NDC0-NDC1)216 is a common data cache block used by the NIX210 and the NPA 214.

Fig. 3 is a simplified block diagram of a subset of the components of network services processor 100 implemented in creating and transmitting outgoing packets. ARM processor 220 generates packet data for transmission. If the packet is to be encrypted, the CPT230 encrypts the packet data before forwarding the packet data to the NIX 210. Otherwise, ARM processor 220 may forward unencrypted packet data directly to NIX 210. The NIX210 then assembles the outgoing packet (e.g., by adding a packet header or other metadata to the formatted data, etc.) and transmits the outgoing packet.

Under previous network encryption techniques, such as those providing IPsec encryption, the processor that originated the packet data repeatedly communicates with the encryption circuitry and interface controller. For example, the processor may forward the encryption instructions to the encryption circuit, and the encryption circuit may return the encrypted packet to the processor. The processor may then forward the encrypted packet to the interface controller for assembly into an outgoing packet. This approach involves additional work by the processor compared to the transmission of unencrypted packets, and additional communication between components can slow down the transmission of packets and reduce the efficiency of the network processor.

Example embodiments provide for on-line encryption of transport packets in a network processor. Referring to fig. 3, the ARM processor 220 can generate packet data for encryption and then forward an encryption instruction to the CPT 230. The CPT then encrypts the packets and forwards the encrypted packets to the NIX210, along with instructions for assembling the various outgoing packets. Thus, ARM processor 220 can provide a single communication per packet regardless of whether the packet is to be encrypted or not, and need not further involve packets following the communication. Thus, packets to be encrypted are processed in series through the modules 220, 230, 210, in parallel with the processing of unencrypted packets (except for invoking the CPT 230). As a result, the workload to ARM processor 220 is reduced and communication between modules 220, 230, 210 is minimized, thereby improving the efficiency and latency of the network processor.

Fig. 4 is a flow diagram of an example process 400 of generating and transmitting an encrypted outgoing packet. Referring to fig. 3, ARM processor 220 may generate a packet (405) and store the packet, along with a corresponding transmit descriptor, to LLC 130 or other memory. The transmit descriptor may also be cached by NDC 216. The transmit descriptor provides instructions for the NIX210 to construct an outgoing packet containing the corresponding packet. For example, the transmit descriptor may include 1) instructions to generate a packet header for an outgoing packet, 2) information attached to the packet header, 3) instructions to break up one large packet into multiple smaller packets, 4) instructions to calculate and insert a checksum into the outgoing packet, 5) instructions to color, shape, police, and/or mark the packet in a particular manner, and/or other information or instructions. ARM processor 220 can then generate encryption instructions for CPT230 to encrypt the packet (415). The encryption instructions may direct the CPT230 to encrypt packets according to a given encryption protocol, such as IPsec. The encryption instructions may also include a pointer to the transmit descriptor, enabling the CPT230 to direct the NIX210 without further action by the ARM processor 220. Thus, the CPT230 can determine the pointer to the transmit descriptor by parsing the encrypted instructions from the ARM processor 220.

The CPT230 accordingly encrypts the packet (415), and may store the corresponding encrypted packet to the LLC 130 or other memory (418). CPT230 may then enqueue the transmit descriptor for processing by NIX210 (420). When CPT230 enqueues the send descriptor, it may first read the send descriptor from memory and then send it to NIX 210. The NIX210 may be responsible for enqueuing transmit descriptors received from the CPT 230. This action may involve caching the send descriptor at the NDC 216. The transmit descriptor may be created by ARM software and may remain unmodified by the CPT230 or the NIX 210.

Alternatively, CPT230 may enqueue the transmit descriptor by forwarding the transmit descriptor pointer to NIX210, or by updating the packet queue of NIX 210. To direct NIX210 to access the encrypted packet, CPT230 may modify the transmit descriptor (or transmit descriptor pointer) to identify the address of the encrypted packet. For example, the CPT230 may add a new pointer to the transmit descriptor, or may overwrite the pointer to the unencrypted packet and replace it with the pointer to the encrypted packet. Alternatively, the CPT230 may write the encrypted packet to the same address as the unencrypted packet to overwrite the unencrypted packet. In another alternative, CPT230 may associate a send descriptor pointer with a pointer to the encrypted packet, forwarding both pointers to NIX 210.

Upon receiving the send descriptor, NIX210 may read the send descriptor and construct an outgoing packet according to instructions in the send descriptor (425). Based on the information provided by the CPT230 as described above, the NIX210 may also access the encrypted packet to incorporate it into the outgoing packet. If the packet is appropriately large, NIX210 may construct a number of outgoing packets corresponding to the packet. The NIX210 may transmit outgoing packets in order (430), and may release the respective packet buffers to the NPA after transmission.

The CPT230 may be further configured to manage encryption operations and workflows. For example, if the CPT230 encounters an error while encrypting a packet, it may avoid encrypting the packet, may communicate with the SSO148 (fig. 1-2) to enqueue work to resolve the error, and/or may cause an interrupt. In response to the interrupt or SSO instruction, ARM processor 220 can determine further action to resolve the error. Additionally, the CPT 220 may manage CPT work queues (e.g., encryption and/or decryption requests). Before enqueuing the CPT instructions, the CPT 220 and/or the ARM processor 220 may confirm that the CPT queue does not overflow. The ARM processor 220 may operate software configured to avoid overflowing the CPT queue and the NIX send queue. For the case of the NIX transmit queue, the NPA 214 may keep the LLC/DRAM location up-to-date with information that effectively describes the NIX transmit queue occupancy. For the CPT queue case, the CPT 220 may utilize the queue occupancy to keep the LLC/DRAM locations up to date. The ARM software may consult these LLC/DRAM locations before deciding to join the CPT queue and/or NIX transmit queue.

In a further embodiment, the CPT may monitor the status of both the CPT queue and the queue implemented by the NIX210 for outgoing packets, such as the NPA buffer 214. Before enqueuing the packet at the NIX210, the CPT230 may check the status of the NPA 240 to verify the buffer capacity. The CPT can avoid enqueuing packets until it verifies the buffer capacity, thereby preventing overflow errors. In further embodiments, one or both of the CPT230 and the NIX210 may issue backpressure commands to upstream modules to prevent overflow. For example, NIX 230 may issue backpressure commands to CPT230, thereby causing CPT230 to avoid enqueuing additional transmit descriptors. The backpressure commands may be direct communications or may be communicated by writing the current queue size to memory.

Fig. 5 is a simplified block diagram of a subset of the components of network services processor 100 implemented in receiving and processing packets. The NPC 212 parses the packet header of the received packet and provides the NPC result. The NPC result provides information for processing the packet and in particular identifies whether the packet is a candidate for decryption. The candidates for decryption may be determined by one or more attributes of the packet, such as an IP address, or may be determined by whether the packet is an IPsec packet. For example, the NPC 212 may limit the eligibility to IPsec packets originating from a given IP address. For packets that meet the criteria, NPC 212 may associate a tag with the NPC result to indicate that it is a candidate for decryption. To process packet data, NIX210 schedules the operation of the ARM processor via SSO 148. If the packet is to be decrypted, the CPT230 decrypts the packet data before forwarding the packet data to the SSO 148. Otherwise, NIX210 may forward the unencrypted packet data directly to SSO 128. The SSO148 manages work queues to schedule work for the ARM processor 220, and the ARM processor 220 processes packets according to corresponding queue entries, such as Work Queue Entries (WQEs).

Under previous network decryption techniques, such as those providing the IPsec protocol, the processor receiving the encrypted packets repeatedly communicates with the decryption circuitry and the interface controller. For example, the processor may first receive an encrypted packet from the interface controller. Because the processor cannot process the encrypted data, it must forward the encryption instructions to the decryption circuitry, and the decryption circuitry can return the decrypted packet to the processor. The processor may then access the decrypted packet data and process the decrypted data as indicated. This approach involves additional work by the processor compared to receiving unencrypted packets, and additional communication between components can slow down the reception of packets and reduce the efficiency of the network processor.

Example embodiments provide for online decryption of received packets in a network processor. Referring to fig. 5, the NIX210 determines whether the received packet is a candidate for decryption (based on the NPC result), and if so, it forwards a decryption instruction to the CPT 230. The CPT then decrypts the packet and updates the WQE at SSO148 to indicate the decrypted packet. Thus, the ARM processor 220 starts the work distribution from the decrypted (or unencrypted) packet and does not need to communicate with the CPT230 to decrypt the packet. Thus, packets to be decrypted are processed in series through the modules 212, 210, 230, 148, 220, in parallel with the processing of unencrypted packets (except for invoking the CPT 230). As a result, the workload to ARM processor 220 is reduced and communication between modules 220, 230, 210 is minimized, thereby improving the efficiency and latency of the network processor.

Fig. 6 is a flow diagram of an example process 600 for receiving and processing packets. Referring to fig. 5, the NPC 212 parses the packet header of the received packet and generates an NPC result indicating whether the packet is a candidate for decryption (605, 610). To process the packet data, NIX210 creates a WQE for SSO148 to allocate work to ARM processor 220 (620). For packets that are not candidates for decryption, NIX210 may enqueue WQEs to SSO148, and SSO148 schedules WQEs (640). SSO148 can maintain a WQE Work Queue Pointer (WQP), which is a pointer to a WQE, in its work queue. When the WQP is at the top of the work queue, the SSO can forward the WQP to the ARM processor 220 to process the decrypted packet according to the WQE (645).

For packets that are candidates for decryption, CPT230 may enqueue WQEs at SSO148 after it decrypts the packet, thereby preserving order and preventing errors. Alternatively, NIX210 may enqueue WQEs, but refrain from doing so until after the packet is decrypted. During this time, WQEs may be stored to memory (e.g., LLC 130 or NDC 216). To decrypt the packet, NIX210 generates and forwards a decrypt command to CPT230 (625).

The CPT230 may then decrypt the packet and write the decrypted packet to memory (e.g., LLC 130 or DRAM 108) (630). After decryption, CPT230 may access the WQE from memory and update it based on the decryption result (635). For example, CPT230 may modify WQEs by adding an indicator as to whether a packet was successfully decrypted and a pointer to the decrypted packet. It may also overwrite the pointer to the encrypted packet with the pointer to the decrypted packet. Alternatively, CPT230 may write the decrypted packet to the same address as the encrypted packet to overwrite the encrypted packet and enable WQE to proceed without modification. In a further alternative, CPT230 may associate WQEs with pointers to decrypted packets without modifying the WQEs themselves, where SSOs may manage both WQEs and pointers.

Once the packet is decrypted and the WQEs are updated accordingly, CPT230 may enqueue the WQEs to SSO148, and SSO148 schedules the WQEs (640). SSO148 can maintain WQEs in its work queue via a Work Queue Pointer (WQP), which is a pointer to a WQE. When the WQP is at the top of the work queue, the SSO can forward the WQP to the ARM processor 220 to process the decrypted packet according to the WQE (645).

7A-7C illustrate data entries implemented in example embodiments. Fig. 7A shows an example WQP 701, fig. 7B shows an example WQE 702, and fig. 7C shows an example encryption result (CPT result) 703. As described above, referring again to fig. 5-6, SSO unit 148 queues each piece of work by adding WQP 701 to the queue. WQP 701 includes an address that points to the corresponding WQE 702 in LLC/DRAM, and a header that enables SSO148 to identify and schedule the corresponding WQE 702. For example, the WQP 701 header may indicate a group, a tag type, and a tag corresponding to each piece of work, and may also indicate whether the corresponding packet is a candidate for decryption.

SSO unit 148 can manage work by keeping WQP 701 to each WQE 702. When the core is available to process new work, SSO148 can store WQP 701 and use the pointer. When WQP 701 is inside SSO unit 148, SSO unit 148 can carry WQP 701 in all locations, since WQP 701 indirectly describes the actual work that needs to be performed. Then, when WQP 701 can be used for processing work, SSO148 can transfer WQP 701 to a core (e.g., ARM processor 220).

In LLC/DRAM, WQE 702 is the primary descriptor that describes each piece of work. WQEs may be created by NIX210 as described above and may contain several fields. The selection of these fields is shown in fig. 7B. The WQE header may include the same information present in the WQE header as described above. The WQE header may also indicate whether the corresponding packet is to be forwarded to CPT230 for decryption. Alternatively, the WQE may contain another entry indicating a decryption instruction sent to CPT 230. The WQE also contains a job description, and a pointer to a corresponding packet in memory (e.g., LLC 130 or DRAM 108).

The CPT result 703 may include an indication of the decryption result. The decryption result may indicate whether the decryption was successful, as well as other information about the decryption or decrypted packet. The CPT result 703 may optionally include a header that provides identification information. In addition, CPT result 703 may also contain a pointer to the decrypted packet in memory if the decrypted packet is written to a different location than the encrypted packet. Upon obtaining CPT result 703, CPT230 may update corresponding WQEs 702 by writing the decryption result and/or a pointer to the decrypted packet to corresponding WQEs 702. Alternatively, CPT230 may forego generating formal CPT results and instead modify the WQE directly by writing a pointer thereto and/or decrypting the results.

Fig. 8 is a simplified block diagram of a subset of the components of network services processor 100 implemented in receiving and processing packets in an alternative embodiment. This configuration may operate in a similar manner to the configuration described above with reference to fig. 5-6, except that SSO148 is replaced by a Completion Queue (CQ) 812. CQ 812 may be different from SSO148 in that it may be a simpler queue managed by NIX210 and may lack some of the scheduling and synchronization functions of SSO 148. For example, CQ 812 may be a component of NIX210 and may contain a single queue or multiple queues for packet processing work. NIX210 may maintain the correct order of work by adding packet entries to CQ 812 in the order packets are received, and then forward work to ARM processor 220 based on CQ 812. As described herein, embodiments of WQEs may be implemented with CQ 812 instead of SSO. In such embodiments, the WQE may serve as an indicator that the corresponding packet needs to be processed, and may omit some features utilized by the SSO148, such as specific instructions for processing the packet.

While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of embodiments encompassed by the appended claims.

Claims (13)

1. A circuit, comprising:

a network parser configured to determine an encryption status from a packet header of a packet, the encryption status indicating whether the packet is a candidate for decryption;

a network interface controller configured to create a queue entry indicating whether packet processing is required for the packet, the network interface configured to selectively forward a decryption command based on the encryption status;

a decryption engine configured to decrypt the packet in response to the decryption command and generate a decrypted packet; and

a packet processor configured to process the packet based on the queue entry, the packet processor accessing one of the packet and the decrypted packet according to the encryption status.

2. The circuit of claim 1, wherein the decryption engine is further configured to: selectively generating a portion of the queue entry in accordance with the encryption status, the portion including a decryption result indicating a location of the decrypted packet.

3. The circuit of claim 2, wherein the packet processor is further configured to: locating the packet in memory based on the queue entry, the processor 1) locating the decrypted packet based on the decryption result, or 2) locating the packet.

4. The circuit of claim 1, wherein the packet processor is further configured to: locating the packet by reading the queue entry in a manner independent of the encryption status.

5. The circuitry of claim 1, wherein the network parser is further configured to: and determining a flow according to the packet header, wherein the flow identifies the working group to which the packet belongs.

6. The circuit of claim 5, wherein the queue entry identifies the flow.

7. The circuit of claim 1, wherein the network interface controller, in response to the encryption status indicating that the packet is not a candidate for decryption, is further configured to: generating the queue entry to indicate a location of the packet.

8. The circuit of claim 1, wherein the packet processor is further configured to: communicating with the encryption engine to decrypt the packet.

9. The circuit of claim 1, further comprising: a queue configured to store a plurality of packets including the packet, the network interface controller further configured to manage entries of the queue.

10. The circuit of claim 1, wherein the network interface controller is further configured to: selectively forwarding the decryption command to the decryption engine based on a state of a queue of decryption requests.

11. The circuit of claim 1, further comprising: a scheduler configured to schedule operation of the packet processor, the scheduler further configured to: scheduling the packet for processing by the packet processor.

12. The circuit of claim 11, wherein the scheduler is further configured to: receiving a decryption result from the decryption engine, the scheduler scheduling the job based on the decryption result.

13. The circuit of claim 1, wherein the queue entry further indicates an instruction for processing the packet.