Network Interface Device

Abstract

The network interface device comprises an input configured to receive a storage response including a plurality of data packets, one or more of the plurality of packets including a header portion and data to be stored, the header portion including a transport protocol header and a data storage application header. A first packet processor is configured to receive two or more of the plurality of packets and perform transport protocol processing of the received packets to provide transport protocol processed packets. A second packet processor is configured to receive the transport protocol processed packets from the first packet processor, write the stored data of the received packets to a memory, and provide the data storage application header and a pointer to the location in memory where the data was written.

Description

Technical Field

[0001] This application relates to network interface devices.

Background Art

[0002] Network interface devices are known and are typically used to provide an interface between a computing device and a network. Some network interface devices can be configured to process data received from the network and / or to process data placed on the network.

[0003] For some network interface devices, there may be a movement to provide a high degree of specialization in design towards specific applications and / or support for increasing data rates.

Summary of the Invention

[0004] The disclosed network interface device includes an input configured to receive a storage response including a plurality of data packets, wherein one or more of the plurality of packets include a header portion and stored data, and the header portion includes a transport protocol header and a data storage application header; a first packet processor configured to receive two or more of the plurality of packets and perform transport protocol processing of the received packets to provide transport protocol processed packets; and a second packet processor configured to receive the transport protocol processed packets from the first packet processor, write the stored data of the received packets to a memory, and provide a data storage application header and a pointer to a location in the memory where the data was written.

[0005] The network interface device may be configured to support at least a portion of the transport protocol processing application, and a second packet processor may be configured to provide the transport protocol processing application with a transport protocol header, a data storage application header, and a pointer to the memory location where the data is written.

[0006] Network interface devices can be configured to support at least some of the data storage applications.

[0007] A data storage application may include one or more of the following: a CEPH application, an NVMe application, and a distributed object store application.

[0008] The network interface device may have a virtualized storage backend function, which is configured to receive storage requests from the host.

[0009] The operating system configured for a data storage application may be different from the operating system of the block storage application making the corresponding storage request.

[0010] Data storage applications can be configured to access the network via a user-space network stack.

[0011] A data storage application can be configured to access the local storage associated with the data space application via a user-space storage stack.

[0012] Data storage applications can be configured to move data using direct memory access via a user-space storage stack.

[0013] Multiple data packets are provided by data storage application read responses, which are provided in response to read requests from the data storage application.

[0014] A network interface device may include a network interface that provides an interface with a network, and the aforementioned network interface is configured to receive the aforementioned read response from the network.

[0015] The network interface device may include a host computer interface that provides an interface with a host computer, and the aforementioned host interface is configured to receive read requests from the host computer.

[0016] A first packet processor may be configured to determine whether one or more of the received packets are out of order, and if it is determined that one or more of the received packets are out of order, the first packet processor may be configured to provide each out-of-order packet, along with its associated instruction, to a second packet processor.

[0017] The second packet processor may be configured to send the data of each unordered packet to the transport protocol processing application without storing the data in memory.

[0018] The second packet processor may be configured to send the data storage application header, the transport protocol header, and the data of each out-of-order packet to the transport protocol processing application without storing the data in memory, and without providing a pointer to a memory location.

[0019] A network interface device may include a transport protocol application, which is configured to provide each unordered packet to the input such that the unordered packets are injected in sequential positions within a group of packets.

[0020] A first packet processor may be configured to process injected packets and provide output to a second packet processor, the aforementioned second packet processor being configured to write stored data of the injected packets into memory.

[0021] A second packet processor may be configured to write the data of each unordered packet into memory.

[0022] A network interface device may include a transport protocol application, which is configured to inject packets based on unordered packets into multiple packets received by the input, in order to the multiple packets, and the injected packets include a transport protocol header, a data storage application header, and a pointer to a memory location where the data is written.

[0023] The network interface device may include a transport protocol application, and the aforementioned transport protocol application is configured to determine whether two or more packets are in order. When it is determined that two or more packets are not in order, the transport protocol application may be configured to inject packets based on out-of-order packets into the correct position in the aforementioned input with respect to other packets among the data packets.

[0024] The network interface device may include a client of a data storage application, and the aforementioned client of the data storage application is configured to fetch a data storage application header for a packet and an associated pointer to a location in memory from a transport protocol processing application and provide an associated output.

[0025] The associated output provided by the client of the data storage application may be configured to cause a direct memory access of data from memory to the host memory of the host computer device.

[0026] The network interface device may include a virtualized storage backend function, and the aforementioned virtualized storage backend function is configured to cause a direct memory access of data from memory to the host memory of the host computer device.

[0027] The transport protocol may include TCP.

[0028] The memory may be DDR memory.

[0029] The network interface device may include a memory into which stored data is written.

[0030] This summary section is provided to merely introduce a concept and is not intended to identify any important or essential features of the claimed subject matter. Other features of the apparatus of the present invention will become apparent from the accompanying drawings and from the following detailed description.

Brief Description of the Drawings

[0031] Some embodiments are illustrated as examples only in the accompanying drawings. However, the drawings should not be construed as limiting the arrangements to only the specific implementations shown. By considering the following detailed description and referring to the drawings, various aspects and advantages will become apparent. [Figure 1] A schematic diagram of a data processing system coupled to a network via a network interface device is shown. [Figure 2a] Network interface devices of some embodiments are shown. [Figure 2b] Subsystems of network interface devices of some embodiments are schematically shown. [Figure 3] Schematic diagrams of hosts and network interface devices of some embodiments are shown. [Figure 4a] An example of a streaming subsystem of a network interface device of some embodiments is shown. [Figure 4b] Another example of a streaming subsystem of a network interface device of some embodiments is shown. [Figure 4c] A streaming processor having an upstream hub and a downstream hub of some embodiments is schematically shown. [Figure 5] An example of a plug-in used to provide additional processing in a streaming subsystem is shown. [Figure 6] Another example of a plug-in being used to replace components within a streaming subsystem is shown. [Figure 7]Capsules used in several embodiments are shown. [Figure 8a] A schematic diagram of the hub architecture used in several embodiments is shown. [Figure 8b] This shows one example of Ingress plugin interface integration. [Figure 8c] This shows an example of egress plugin interface integration. [Figure 9] This shows a change in the purpose of the caching subsystem within the streaming subsystem. [Figure 10] This illustrates different trust domains for network interface devices in several embodiments. [Figure 11] The two confidence areas indicate that one is isolated from the other. [Figure 12a] This example shows two trust areas with different privilege levels. [Figure 12b] This example shows two trust areas with the same privilege level. [Figure 13] Several embodiments of data storage virtualization on network interface devices are shown. [Figure 14] A more detailed view of some of the exemplary network interface devices shown in Figure 13. [Figure 15] Several embodiments of the method are shown. [Figure 16] Several embodiments are shown, along with alternative methods. [Figure 17] Several embodiments are shown, along with alternative methods. [Modes for carrying out the invention]

[0032] This disclosure concludes with claims defining novel features, but the various features described herein are best understood in conjunction with the drawings. The processes, machines, manufactures, and any variations thereof described herein are provided for illustrative purposes only. The specific structural and functional details described herein are not intended to be limiting, but merely representative foundations to teach those skilled in the art to adopt various features described substantially in any appropriately detailed structure, as the basis for the claims. Furthermore, the terms and phrases used herein are not intended to be limiting, but to provide an understandable description of the features described.

[0033] When data is transferred between two data processing systems via a data channel, each data processing system has a suitable network interface that allows it to communicate across the channel. The data channel may be provided by a network. For example, the network may be based on Ethernet technology or any other suitable technology. The data processing systems may be provided with a network interface that can support the physical and logical requirements of the network protocol. The physical hardware components of the network interface are called a network interface device or network interface card (NIC). In this specification, a network interface device is referred to as a NIC. It should be understood that a NIC may be provided in any suitable hardware form, such as an integrated circuit or a hardware module. A NIC is not necessarily implemented in the form of a card.

[0034] A computer system may have an operating system (OS) for user-level applications to communicate with a network. The part of the operating system known as the kernel includes a protocol stack for translating commands and data between applications and device drivers specific to the network interface card (NIC), and device drivers for directly controlling the NIC. By providing these functions within the operating system kernel, the complexity of the NIC and the differences between them can be hidden from user-level applications. In addition, network hardware and other system resources (such as memory) can be securely shared among many applications, protecting the system from flawed or malicious applications.

[0035] A typical data processing system 100 for performing transmissions over a network is shown in Figure 1. The data processing system 100 comprises a host computing device 101 coupled to a NIC 109 that is configured to interface the host to a network 103. The host computing device 101 includes an operating system 104 that supports one or more user-level applications 105. The host computing device 101 may also include a network protocol stack (not shown). The network protocol stack may be a Transmission Control Protocol (TCP) stack or any other suitable protocol stack. The protocol stack may be a transport protocol stack.

[0036] Application 105 can send and receive TCP / IP (Internet Protocol) messages by opening a socket and reading and writing data to the socket, and the operating system 104 transmits the messages over the network.

[0037] Some systems may at least partially offload the protocol stack to the NIC 109. For example, if the stack is a TCP stack, the NIC 109 may have a TCP Offload Engine (TOE) to perform TCP protocol processing. Performing protocol processing on the NIC 109 rather than the host computing device 101 can reduce the demands on the processor(s) of the host system 101. Data sent over the network may be sent by application 105 via a TOE-enabled virtual interface driver, completely bypassing the kernel TCP / IP stack. Therefore, data sent along this high-speed path only needs to be formatted to meet the requirements of the TOE driver.

[0038] The host computing device 101 may comprise one or more processors and one or more memories. In some embodiments, the host computing device 101 and the NIC 109 may communicate via a bus, such as a peripheral component interconnect express (PCIe bus).

[0039] During the operation of the data processing system, data to be transmitted over the network may be forwarded from the host computing device 101 to the NIC 109 for transmission. In one embodiment, data packets may be forwarded directly from the host to the NIC by the host processor. The host may provide data to one or more buffers 106 located on the NIC 109. The NIC 109 may then prepare the data packets and transmit them over the network 103.

[0040] Alternatively, the data may be written to a buffer 107 within the host system 101. Some systems may support both of these data transfer mechanisms. The data may then be retrieved from buffer 107 by the NIC and transmitted over the network 103.

[0041] In both of these cases, the data may be temporarily stored in one or more buffers before being transmitted over the network.

[0042] The data processing system can also receive data from the network via NIC109.

[0043] The data processing system may be any type of computing device, such as a server, personal computer, or handheld device. Some embodiments may be suitable for use in a network operating TCP / IP over Ethernet. In other embodiments, one or more different protocols may be used. The embodiments may be used with any suitable wired or wireless network.

[0044] Refer to Figure 2a, which shows NIC109 in several embodiments. The network interface may be provided at least partially by one or more integrated circuits. Alternatively, the NIC may be part of a larger integrated circuit. The NIC109 may be provided by a single hardware module or by two or more hardware modules. The NIC may provide a network-connected CPU in front of the main CPU. The NIC is located on the data path between the host CPU and the network.

[0045] NICs can be configured to provide application-specific pipelines to optimize data movement and processing. NICs can integrate high-level programming abstractions for the network and compute acceleration.

[0046] Some embodiments of the NIC may support terabit-class endpoint devices. Some embodiments may be capable of supporting terabit data rate processing. For example, the NIC may receive data from and / or place data into the network at terabit data rates. However, it should be understood that other embodiments may operate and / or support lower or higher data rates.

[0047] The device in Figure 2a can be considered to provide a System-on-Chip (SoC). The SoC shown in Figure 2 is an embodiment of a programmable integrated circuit (IC) and an integrated programmable device platform. In the example in Figure 2, various different subsystems or regions of NIC109 may be mounted on a single die provided within a single integrated package. In other examples, various subsystems may be mounted on multiple interconnect dies provided as a single integrated package. In some embodiments, the NIC109 in Figure 2 may be provided by two or more packages, integrated circuits, or chiplets.

[0048] In the embodiment, the NIC 109 includes multiple regions having circuit mechanisms with different functionalities. In the embodiment, the NIC 109 has a processing system provided by one or more CPUs 111. The NIC 109 has one or more first transceivers 116 for receiving data from and / or placing data on the network. The NIC 109 has one or more virtual switches (vSwitches) or protocol engines 102, which will be described in more detail later. The protocol engine may be a transport protocol engine. This function will be referred to as the virtual switch function below. The NIC 109 has one or more MAC (medium access control) layer functions 114. The NIC 109 has one or more second transceivers 110 for receiving data from and / or providing data to a host. The NIC 109 has one or more PCIe (Peripheral Component Interconnection Express) interfaces 112.

[0049] The NIC has one or more DMA (direct memory access) adapters 117. The DMA adapters provide a bridge between the memory domain and the packet streaming domain. This can support inter-memory transfers. This will be explained in more detail below.

[0050] NIC109 may have one or more processing cores 108, or access to them. As just one example, the cores may be ARM processing cores and / or any other suitable processing cores.

[0051] NIC109 has a network-on-chip (NoC) 115, which is shaded in Figure 2a. This can provide a communication path between different parts of NIC109. Please note that two or more components on NIC109 may communicate via direct connection paths and / or dedicated enhanced bus interfaces, either alternatively or additionally.

[0052] The area between NoCs may contain one or more components. For example, the area may house one or more programmable logic (PL) blocks 113. This area is sometimes called a fabric. As just one example, the programmable logic block may be provided at least partially by one or more FPGAs (Field programmable gate arrays). The area may house one or more lookup table LUTs. One or more functions may be provided by the programmable logic block. Some embodiments of these functions will be described later. The ability to adapt to different functions in this area may allow the same NIC to be used to meet various different end-user requirements.

[0053] It should be understood that in other embodiments, any other suitable communication device may be used on the NIC instead of or in addition to the NoC.

[0054] A NIC provides an interface between a host device and a network. The NIC enables data to be received from the network. This data can be provided to the host device. In some embodiments, the NIC may process the data before it is provided to the host device. In some embodiments, the NIC enables data to be transmitted by the network. This data can be provided by the host device and / or the NIC. In some embodiments, the NIC may process the data before it is transmitted by the network.

[0055] Virtual switch 102 may be part of a device or NIC that is at least partially enhanced.

[0056] There may be a single virtual switch or two or more separate virtual switches.

[0057] The virtual switch 102 can communicate with other blocks on the chip using a NoC and / or via a direct connection path and / or a dedicated enhanced bus interface. In some embodiments, this may depend on the capacity of the NoC relative to the amount of data being transmitted. The NoC may be used, for example, for memory access by the NIC 109. The NoC 115 may be used, for example, to distribute data to the CPU 111, processor 108, DMA adapter 117 and / or PCIe block 112.

[0058] In some embodiments, NoC and / or direct connection paths and / or dedicated enhanced bus interfaces may be used to deliver data to one or more accelerator kernels and / or other plug-ins, as will be described in more detail later. In some embodiments, routing may be via programmable logic. These plug-ins may be provided by programmable logic 113 in some embodiments.

[0059] The virtual switch 102 is physically located on the edge region of the NIC 109 and can communicate with various other components of the NIC 109. In some embodiments, the virtual switch 102 may be located in close proximity to the MAC layer function 114 and one or more first transceivers 116. These components may be located in close proximity to the edge region of the NIC 109. Data from the network is received by one or more first transceivers 116.

[0060] In other embodiments, the virtual switch 102, MAC layer function 114, and one or more first transceivers 116 may be located physically away from the edge region of the NIC.

[0061] Some embodiments may allow for the provision of customized NIC functionality. This may be useful when specific NIC functionality is required. This may be for a particular application or multiple applications, or for a specific use of the NIC. This may be useful when the number of devices required to support that NIC functionality is relatively small. Alternatively or additionally, this may be useful when NIC customization is desired. Some embodiments may provide a flexible NIC.

[0062] Customization can be supported by providing one or more functions using PL113.

[0063] Some embodiments may be used to support relatively high date rates.

[0064] Refer to Figure 2b, which schematically shows the communication paths between subsystems of the NIC in Figure 2a. The host PCIe interface 112 and the DMA controller 117 communicate via the memory bus. The DMA controller 117 communicates via the memory fabric 140 using the memory bus. The management controller 130 provides control plane messages via the memory fabric 140 using the control bus. The application processor 111 communicates via the memory fabric 140 using the memory bus. Data is received in the DDR memory 142 via the memory fabric using the memory bus.

[0065] The DMA controller 117 communicates with one or more virtual switches 102 via the packet bus. One or more virtual switches may provide packet processing. One or more virtual switches may perform offload processing and virtual switching, as will be described in more detail later. The processing provided by one or more virtual switches may be modified using one or more plug-ins 144, which in one embodiment is implemented using the PL block 113 in Figure 2a. The plug-ins may communicate with the memory fabric via the memory bus and with one or more virtual switches via the packet bus. One or more virtual switches may communicate with MAC 114 via the packet bus.

[0066] In some embodiments, data encapsulation can be used to transmit data within the NIC. This will be described in more detail below.

[0067] Refer to Figure 3, which shows a schematic diagram of the functional blocks supported by the host device 101 and NIC 109. NIC 109 includes a virtual switch function 102, which is extensible by one or more plug-ins, as will be described in more detail later.

[0068] The virtual switch function 102 with plug-ins can support custom protocols and switch actions.

[0069] The host device 101 has several virtual machines VM122.

[0070] Several PCIe PFs (physical functions) and / or VFs (virtual functions) may be supported. A PCIe function 118 may have multiple virtual NICs (VNICs). Each VNIC 126 may be connected to a separate port on a virtual switch. Figure 3 shows one PCIe function and one VNIC for the PCIe function for clarity.

[0071] Each vNIC 126 may have one or more VIs (Virtual Interfaces) 127. Each VI may provide a channel for sending and receiving packets. Each VI may have a transmit queue TxQ, a receive queue RxQ, and an event queue EvQ. A one-to-one relationship may exist between a virtual machine and a virtual function. In some embodiments, there may be multiple VIs mapped to a VF (or PF).

[0072] In some embodiments, one of the VIs within a given PF or VF may support a function management interface.

[0073] The virtual switch 102 has multiple virtual ports. The ports can be configured to receive data from the VNIC's TxQ and send data to the VNIC's RxQ.

[0074] The virtual switch 102 is configured to interface with one or more application CPUs provided, for example, by CPU 111, a management controller 130 configured to control the virtual switch, and one or more MAC layer functions 114.

[0075] In some embodiments, the virtual switch is extensible by plug-ins as discussed earlier. One embodiment of a plug-in includes a hardware accelerator 128.

[0076] Refer to Figure 4a, which shows an example of a streaming subsystem 200 in several embodiments provided by the NIC.

[0077] A pipeline exists on the transmit and receive paths of the streaming subsystem. To provide some flexibility to end-user applications, as will be described in more detail, the streaming subsystem allows for the addition of one or more plugins. Plugins can be added to the data path of the pipeline. One or more plugins can be provided by programmable logic 113. Other components of the data pipeline can be provided by enhanced logic or circuitry. Components of the data pipeline provided by enhanced logic or circuitry can be provided by virtual switch functionality.

[0078] Using plugins can sometimes make device customization easier. This can allow the same device to be customized for different end users or applications. Alternatively or additionally, using plugins can make it possible for the same device architecture to be used for several different applications.

[0079] Data may exit the data path at a certain point, proceed to a plugin, and be reinjected into the data path. This reinjection may occur through the same or a different plugin. The data may or may not be reinjected into the data path. This will be explained in more detail below.

[0080] A scheduler is provided to control the movement of data along a data path. Each stage of the data path is controlled by the scheduler. Plugins are also scheduled by their respective schedulers. The scheduler manages resources (such as buffers) that may be contested downstream of a given plugin. This will be explained in more detail below. The scheduler may be provided by enhanced logic or circuitry.

[0081] A streaming subsystem may support multiple data interfaces. In some embodiments, one or more data interfaces may be full-duplex. This means that a data interface may have half ingress and half egress. In some embodiments, one or more data interfaces may be half-duplex. This means that a data interface supports either ingress or egress data. Ingress refers to the input of data into the streaming subsystem, and egress refers to the output of data from the streaming subsystem.

[0082] The data interface may use the inter-component streaming bus (ICSB) format or any other suitable bus format.

[0083] The DMA (Direct Memory Access) adapter interface 202 is used to pass data between the streaming subsystem and the DMA engine. The DMA adapter interface provides a data interface. In some embodiments, there may be one DMA adapter. In other embodiments, there may be multiple DMA adapters. This will be described in detail later.

[0084] In the embodiment shown in Figure 4a, one DMA adapter interface 202 is shown for a "host-to-card" H2C data flow, i.e., a data flow from the host computer to the NIC. In some embodiments, more than one H2C DMA adapter may be provided. This may depend, for example, on the required data rate and / or the available area on the NIC. In some embodiments, two H2C DMA adapters may be provided. In other embodiments, one H2C DMA adapter may be provided. In some embodiments, more than two H2C DMA adapters may be provided.

[0085] One DMA adapter interface 204 may be provided for the C2H interface. C2H stands for "card-to-host" data flow, i.e., from the NIC to the host computer. The DMA adapter interface may place the data on the NoC (or fabric).

[0086] In some embodiments, the number of C2H adapters is the same as the number of H2C DMA adapters. In some embodiments, the number of C2H adapter interfaces is different from the number of H2C DMA adapter interfaces.

[0087] In some embodiments, a single DMA adapter may support both C2H and H2C data flows. This may be supported by separate DMA adapter interfaces or a shared adapter interface. In other embodiments, a DMA adapter for C2H data flows may differ from a DMA adapter for H2C data flows. This may be supported by separate DMA adapter interfaces.

[0088] DMA provides a bridge between the memory domain and the packet streaming domain, as schematically shown in Figure 2b. In some embodiments, DMA can support inter-memory transfers. These embodiments will be described in more detail later.

[0089] DMA may use a descriptor ring for commands from the host to the NIC and a completion ring for notifications from the NIC to the host. DMA may support reading from and writing to memory. Memory may be located at least partially within the host.

[0090] In some embodiments, more than one type of DMA access may be supported, requiring a dedicated capture interface to support it. For example, adapters may exist that support standardized approaches such as Virtio (sometimes referred to as VirtIO), and / or vendor-specific and / or customized approaches.

[0091] The output of the H2C DMA adapter interface 202 is provided to a first hub 252. The first hub 252 is located between the H2C DMA adapter interface 202 and the VNIC-TX (Virtual NIC Transmit) engine 240. In some embodiments, the hub can support at least one streaming inbound plug-in and / or at least one streaming outbound plug-in. This may allow users to access data streams before and / or after each engine. The hub may be provided by enhanced logic or circuitry.

[0092] Please note that if two or more H2C DMA adapter interfaces 202 are provided, a single hub may be used to support them.

[0093] The H2C DMA is configured to collect one or more packets from memory and stream them to the first hub 252 via adapter 202. This is under the control of the first scheduler 203a.

[0094] The first scheduler 203a is notified of the output data by the H2C DMA adapter and can issue a job request to the H2C DMA adapter.

[0095] The first hub 252 has one or more first egress plugins 214a. If there is one H2C DMA adapter, there may be one egress plugin. If there are two H2C DMA adapters, there may be two egress plugins. This provides connectivity from the host to the plugin (H2P). In other embodiments, there may be a different number of egress plugins compared to the number of DMA adapters.

[0096] The first hub 252 has one or more second ingress plugins 214b, which provide connectivity from the plugins to the virtual NIC (TX) engine (P2VNT). If there is one H2C DMA adapter, there may be one ingress plugin. If there are two H2C DMA adapters, there may be two ingress plugins. In other embodiments, there may be a different number of ingress plugins compared to the number of DMA adapters.

[0097] If there are two half-bus-width data interfaces, the first hub may be configured to process the received data in order to provide full-bus-width data output. A plug-in interface may support the total bandwidth of the pipeline at the point where the plug-in is made. Depending on the implementation, this may be a single bus interface or a collection of narrower buses. The DMA adapter may be accessed by the NoC or through the fabric.

[0098] The second scheduler 203b is configured to control the output of data by the first hub 252.

[0099] The first hub 252 provides output to the VNIC-TX (Virtual NIC Transmit) engine 240. The VNIC-TX engine 240 processes packets sent by the driver via the DMA adapter and / or packets received via the ingress interface through the host interface and can perform one or more of the following functions on behalf of the driver: - Checksum Offroad - VLAN (Virtual Local Area Network) insertion offload - Packet validation (e.g., source address, firewall, and / or similar).

[0100] In other embodiments, one or more alternative or additional functions may be performed.

[0101] The VNIC-TX engine is configured to output data to the second hub 254.

[0102] The second hub 254 has one or two egress plug-ins 214c, which provide connectivity from the virtual NIC (TX) engine to the plug-in VNT2P. If there is one H2C DMA adapter 204, there may be one egress plug-in. If there are two H2C DMA adapters, there may be two egress plug-ins. In other embodiments, there may be a different number of egress plug-ins compared to the number of DMA adapters.

[0103] The second hub 254 has one or two ingress plugins 214d, which provide connectivity from the plugins to the MAE (match action engine) 244 (P2HMAE) from the host side.

[0104] If there is one H2C DMA adapter 204, there may be one ingress plugin. If there are two H2C DMA adapters, there may be two ingress plugins. In other embodiments, there may be a different number of ingress plugins compared to the number of DMA adapters.

[0105] The third scheduler 203c is configured to control the output of data by the second hub 254.

[0106] The second hub provides output to MAE 244. In some embodiments, MAE 244 utilizes a caching subsystem 215 provided for the streaming subsystem. MAE can perform any preferred functions, such as analysis matching action functions, encapsulation functions, and / or decapsulation functions.

[0107] The MAE engine can implement virtual switching functionality using a rule-driven analysis-match action engine. For example, rules are provided by the driver. Each rule may provide a set of matching criteria and a set of actions to apply to packets that satisfy those criteria.

[0108] The MAE engine can perform virtual switching functions and other offloading tasks. Mapping packets from the ingress virtual port to the egress virtual port, Replicating packets to two or more egress ports, Encapsulation and decapsulation, Connection tracking and NAT (Network Address Translation), Packet filtering and, Packet labeling and, ECN (Explicit Congestion Notification Marking), This may include one or more of the following: packet and byte counts.

[0109] MAE is The match engine (ME) is a streaming processor that analyzes packets and performs rule table lookups within the cache subsystem. A regeneration hub that duplicates packets when necessary and performs packet drops, It may include an action engine (AE), which is a streaming process that invokes actions indicated by matching rules.

[0110] The matching engine first analyzes the incoming packet. This can be a three-step process. 1. Analyze external headers that may be part of the encapsulation. Analyzed headers include Ethernet, VLAN (Virtual Local Area Network), IP (Internet Protocol), and UDP (User Datagram Protocol) headers. 2. Look up the header fields and source ports in the external rule table, located in STCAM (smart ternary content addressable memory) or BCAM (binary content addressable memory) or any other suitable memory of the cache subsystem. The key is formed from a subset of the header fields plus some metadata, and the rule matches an arbitrary subset of the key bits. The lookup result may identify one or more of the following: existing encapsulation (if any), connection tracking fields (for later use), and the external rule ID. 3. Parse the remaining encapsulation headers (if any) and the internal headers (or internal headers only). Parsing restarts at the beginning of the frame. If encapsulation exists, headers already parsed in step (1) and identified as part of the encapsulation are skipped. Typically, further encapsulation headers are then parsed, followed by the internal headers. If encapsulation does not exist, internal frame parsing restarts at the beginning of the frame.

[0111] MAE 244 provides output to the third hub 256. The third hub 256 is provided between MAE 244 and the VNIC-RX engine 242.

[0112] The third hub 256 has one or two ingress plug-ins 214f, which provide connectivity from the MAE engine to the plug-ins (HMAE2P). If there is one H2C DMA adapter 204, there may be one ingress plug-in. If there are two H2C DMA adapters, there may be two ingress plug-ins. In other embodiments, there may be a different number of ingress plug-ins compared to the number of DMA adapters.

[0113] The third hub 256 has one or two egress plug-ins 214e, which provide connectivity from the plug-ins to the virtual NIC (RX) engine (P2VNR). If there is one H2C DMA adapter 204, there may be one egress plug-in. If there are two H2C DMA adapters, there may be two egress plug-ins. In other embodiments, there may be a different number of egress plug-ins compared to the number of DMA adapters.

[0114] The third hub may optionally have one or more further egress plugins 214i. This provides connectivity from the MAE (match action engine) 244 to the plugin (NMAE2P) from the network destination. There may be no ingress plugins for half of the network configuration of the third hub 256, because injecting data at this location is equivalent to sending data directly to the TX MAC, which is supported in some embodiments. In other embodiments, one or more ingress plugins may be supported by half of the network configuration of the third hub 256.

[0115] If there is one H2C DMA adapter 204, there may be one further egress plugin. If there are two H2C DMA adapters, there may be two further egress plugins. In other embodiments, there may be a different number of further egress plugins compared to the number of DMA adapters.

[0116] Alternatively or additionally, there may be interconnections that route traffic between each hub plugin interface, the streaming subsystem, and several DMA adapters. These interconnections can be considered ingress plugins and / or egress plugins. For example, this could be a bus structure created with NoC, or programmable logic.

[0117] The VNIC-RX engine or processor can handle packets destined for the host or embedded processor. It can perform one or more of the following functions on behalf of the receiving driver: - Packet classification - Checksum function, e.g., calculation and verification. - Flow steering and / or RSS (Receiver Scaling) - Packet filtering

[0118] The fourth scheduler 203d is configured to control the output of data by the third hub 256.

[0119] The VNIC-RX engine 242 is configured to output data to the fourth hub 258.

[0120] A fourth hub 258 is provided between the VNIC-RX engine 242 and the C2H DMA adapter 204.

[0121] The fourth hub 258 has one or two egress plug-ins 214g, which provide connectivity from the virtual NIC (RX) engine to the plug-ins (VNR2P). If there is one H2C DMA adapter 204, there may be one egress plug-in. If there are two H2C DMA adapters, there may be two egress plug-ins. In other embodiments, there may be a different number of egress plug-ins compared to the number of DMA adapters.

[0122] The fourth hub 258 has one or two ingress plug-ins 214h, which provide connectivity from the plug-ins to the C2H DMA adapter (P2H). If there is one H2C DMA adapter 204, there may be one ingress plug-in. If there are two H2C DMA adapters, there may be two ingress plug-ins. In other embodiments, there may be a different number of ingress plug-ins compared to the number of DMA adapters.

[0123] The fifth scheduler 203e is configured to control the output of data by the fourth hub 258.

[0124] One or more network port receiving streaming engines (NET_RX) 206 are provided to pass data from one or more MACs (medium access controllers) 210 to the streaming subsystem. The NET_RX engine can convert the MAC bus interface to a bus format used by the streaming subsystem. As just one example, this could be an ICSB bus. In some embodiments, there may be one NET_RX engine instance configured to receive data from RX MACs. In some embodiments, there may be two NET_RX engine instances, each NET_RX engine configured to receive data from n RX MACs, where n can be any preferred number, and in some embodiments it is 8. The NET_RX is used to enable data to be passed from the receiving MACs to the streaming subsystem.

[0125] NET_RX206 is configured to provide an output to the fifth hub 260. This allows network RX data to be sent to user logic while utilizing the data buffer provided by the fifth hub. The fifth hub may be optional in some embodiments.

[0126] The fifth hub may optionally have one or more egress plugins 214k. If there is one H2C DMA adapter 204, there may be one egress plugin. If there are two H2C DMA adapters, there may be two egress plugins. In other embodiments, there may be a different number of egress plugins compared to the number of DMA adapters.

[0127] The fifth hub 260 may provide output to the second hub 254.

[0128] The fifth hub 260 may be used in conjunction with an egress plug-in for data. This may allow, for example, to bypass the rest of the pipeline. This may allow, for example, received data to be directed to the NIC fabric via an egress buffer. Scheduling is managed by the scheduler (not shown) of this hub.

[0129] The third hub, 256, can be used in conjunction with a plugin to handle data ingress. This could, for example, allow the rest of the pipeline to be bypassed. This would allow data from the fabric to be directed to the TX portion via an ingress buffer. Scheduling is managed by one of the schedulers.

[0130] It should be noted that the second hub 254 may optionally have one or more additional ingress plugins 214j. This provides connectivity from the plugins to the MAE (Match Action Engine) 244 (P2NMAE) from the network side. If there is one H2C DMA adapter 204, there may be one additional ingress plugin. If there are two H2C DMA adapters, there may be two additional ingress plugins. In other embodiments, there may be a different number of ingress plugins compared to the number of DMA adapters.

[0131] One or more network port transmit streaming engines (NET_TX208) are provided to pass data from the streaming subsystem to one or more transmit MACs (Media Access Controllers) 212. (These MACs may be MACs 114 shown in Figures 2a, 2b, and 3.) In some embodiments, there may be one NET_TX engine instance configured to send data to TX MACs. In some embodiments, there may be two NET_TX engine instances, each NET_TX engine configured to send data to n TX MACs, where n can be any preferred number, and in some embodiments it is 8. The NET_TX engine may be configured to cover the bus format of the streaming subsystem to the bus format of the MACs.

[0132] NET_TX 208 is configured to receive output from the third hub 256. The sixth scheduler 203f is configured to control the output of data from the third hub to NET_TX 208.

[0133] Alternatively or additionally, there may be interconnections that route traffic between each hub plugin interface, the streaming subsystem, and several MA adapters. These interconnections can be considered ingress plugins and / or egress plugins. For example, this could be a bus structure created with NoC, or programmable logic.

[0134] As discussed, one or more plug-in interfaces are provided by one or more hubs. In some embodiments, a plug-in interface may be an ingress plug-in interface that injects data into a streaming subsystem data path. In some embodiments, a plug-in interface may be an egress plug-in interface used to extract data from a streaming subsystem data path. Data may be provided by and to a user kernel and / or other functions. The user kernel and / or other functions may be provided by other parts of the NIC. In some embodiments, the user kernel or other functions may be provided by programmable logic. In some embodiments, the user kernel and / or other functions may be provided by hardware. In some embodiments, the user kernel and / or other functions may be used to enable customization of the NIC to meet the end-use requirements of the NIC.

[0135] In some embodiments, the number of ingress and egress plugin interfaces may be the same. For example, there may be 10 ingress plugins and 10 egress plugins. In other embodiments, there may be more or fewer than 10 ingress / egress plugins. In some embodiments, the number of ingress plugins and egress plugins may differ.

[0136] In some embodiments, the plug-in interface may support bidirectional data ingress and egress.

[0137] In some embodiments, there may be fewer plugin interfaces than plugins. In these embodiments, the plugin interfaces may multiplex traffic to and from several plugin points. The number may be two or more.

[0138] Plugins may have a full-width bus interface or a half-width bus interface. If a plugin has a half-width bus interface, it may be provided in pairs. This may allow the plugin to match the full speed of the streaming subsystem data path at each point. The streaming subsystem data path may operate on a full-width bus.

[0139] If a plug-in interface has a full-width interface, there can only be one plug-in interface associated with a given injection or extraction point.

[0140] The VNICTX engine 240, MAE 244, VNICRX engine 242, NET_RX engine 206, and NETTX ​​engine 208 are non-limiting embodiments of the data processing engine.

[0141] Refer to Figure 4c, which schematically shows a streaming processor or engine. The streaming processor has an upstream hub and a downstream hub. This allows the user to access data streams before and after each engine. The device shown in Figure 4c is used in the devices shown in Figures 4a and 4b.

[0142] In some embodiments, the hub is common to both the receive and transmit flows. This can enable flexible data flow between the receive and transmit paths.

[0143] A hub may have one or more ingress plugins and one or more egress plugins.

[0144] Streaming processors generally do not block. Generally, streaming processors aim to avoid back pressure except in transient cases. The system may support several virtual channels that allow for prioritizing flows and adapting to blocking behavior. For example, flow lookups are performed in the local cache, and flow entries do not reside in the local cache. Fetching from remote memory (e.g., DDR) may need to be performed, which may require several clock cycles. The cache subsystem may support pipelined lookups and numerous pending remote memory read requests, but in traffic patterns with low cache locality, processing some flows may cause line-head blocking. Virtual channels can prevent this blocking from affecting other flows from other virtual channels.

[0145] Streaming processors can support a specific bandwidth.

[0146] A hub can provide downstream buffering for upstream processors and plugins that wish to inject data into the streaming subsystem. Each hub may contain or be controlled by a scheduler to allow data to be extracted / injected simultaneously from all plugins as needed. Hubs can be used to create customizations (including loops) to the pipeline. The scheduler shown in Figure 4c is for scheduling upstream hubs. Destination credits for downstream hubs are used by the scheduler.

[0147] Returning to the device in Figure 4a, the transmission path may be as follows: Data transmission may be initiated by a host or application CPU providing one or more entries to one or more DMA transmission queues. The H2C DMA adapter interface 202 provides output to the VNIC TX engine 240 via the first hub 252. The VNIC TX engine 240 provides output to the MAE 244 via the second hub 254. The MAE 244 may provide virtual switch functionality between the transmission and reception paths. The MAE 240 provides output to the NET_TX engine 208 via the third hub 256. The NET_TX engine 208 provides output to the transmission MAC 212.

[0148] The receiving path may be as follows: Data from the network may be received by the receiving MAC 210, which provides output to the NET_RX engine 206. The NET_RX engine provides output to the MAE 244 via the fifth hub 260 and the second hub 254. The MAE 244 provides output to the VNIC_RX engine 242 via the third hub 256. The VNIC_RX engine 242 provides output to the C2H DMA adapter interface via the fourth hub 258.

[0149] The host loop path may be as follows: Data transmission may be initiated by a host or application CPU providing one or more entries to one or more DMA transmit queues. The H2C DMA adapter interface 202 provides output to the VNIC_TX engine 240 via the first hub 252. The VNIC_TX engine 240 provides output to the MAE 244 via the second hub 254. The MAE 244 provides output to the VNIC_RX engine 242 via the third hub 256. The VNIC_RX engine provides output to the C2H DMA adapter interface via the fourth hub 258.

[0150] The inter-network flow path may be as follows: Data from the network may be received by the receiving MAC 210, which provides output to the NET_RX engine 206. The NET_RX engine 206 provides output to the MAE 244 via the fifth hub 260 and the second hub 254. The MAE 240 provides output to the NET_TX engine 208 via the third hub 256. The NET_TX engine 208 provides output to the transmitting MAC 212.

[0151] In some embodiments, a bus connection is provided between each of the entities in Figure 4a. In some embodiments, the bus connections provided between each of the entities may be of the same width. In some embodiments, data is injected into the streaming subsystem using the full bus width. In other embodiments, data may be injected into the streaming subsystem using half the bus width. In the latter case, a pair of data injection entities may exist.

[0152] The data injection entity may include one or more plug-ins, DMA adapters, and / or receiving MAC 210s.

[0153] In some embodiments, data is removed from the streaming subsystem using the full bus width. In other embodiments, data may be removed from the streaming subsystem using half the bus width. In the latter case, a pair of data removal entities may exist.

[0154] The data removal entity may include one or more plug-ins, DMA adapters, and / or transmit MAC 212s.

[0155] In some embodiments, the MAE is required to handle traffic from the VNIC TX engine 240 and the network port receive streaming engine NET_RX206. Each of the VNIC TX engine and the network port receive streaming engine NET_RX206 may support a data rate of up to X. Potentially, the MAE may then need to support a data rate of up to 2X.

[0156] In some embodiments, depending on the usage scenario, the average data rate that actually needs to be supported by the MAE is only X. In that case, the MAE can operate at the same rate as the VNIC TX engine and the network port receive streaming engine NET_RX206. Thus, the bus between the MAE and its hub can be the same width as the other buses in the streaming subsystem.

[0157] In other embodiments, the data rate that needs to be supported by the MAE may exceed X. In some embodiments, the MAE may need to support a data rate of up to 2X. This can be supported by modifying the bus to and from the MAE. The bus width may be increased (e.g., doubled) and / or the clock rate of the bus may be increased.

[0158] Some embodiments may utilize a segmented bus. A segmented bus is a streaming bus in which the overall data path width is divided into physically distinct parts. Each segment has its own main control signal (e.g., SOP (start of packet) and EOP (end of packet)). Segmented buses can be used to overcome the potential inefficiencies of any fixed-width bus carrying capsules of arbitrary sizes. Without segmentation, if a capsule is (e.g.) one byte longer than the bus width, it would take two bus beats (clock cycles) to carry the capsule, and the rest of the bus, except for one byte, would carry nothing in the second beat. A segmented bus allows the next capsule to begin transmission in the second bus beat in the above embodiments, recovering much of the wasted bandwidth. As the number of segments increases, the bus bandwidth for arbitrary capsule sizes tends to approach 100% of its theoretical maximum. However, this needs to be balanced with the complexity and resources of the multiplexing and demultiplexing operations required with increasing segmentation. The advantages of a segmented bus can outweigh the advantages of an unsegmented bus, such as increasing its width or clock speed. This may depend on the required implementation. The number and width of segments may vary depending on the constraints.

[0159] In many cases, a bus can be divided into four segments, but this can vary depending on how tight the constraints are.

[0160] The number of segments supported can be modified by the frame size and / or bus width.

[0161] MAE can operate at a higher data rate than other engines.

[0162] One modified example is shown in Figure 4b. In this modified example, two MAE engines 244a and 244b are provided. The first MAE 244a can be considered a host MAE that processes data from a host. The second MAE 244b can be considered a network MAE that processes data from a network. Each MAE provides an output to a third hub 256. It should be noted that in other embodiments, there may be more than two MAE engines arranged in parallel.

[0163] The second hub function in Figure 4a is provided by two hubs 254a and 254b. Hub 254a is configured to receive output from the VNIC TX engine, along with any plug-ins associated with it. Hub 254a is configured to provide output to the first MAE 244a. Hub 254b is configured to receive output from the NET_RX engine 206, along with any plug-ins associated with it. Hub 254b is configured to provide output to the second MAE 244b.

[0164] The scheduler 203c can receive input from both MAE engines and both hubs 254a and 254b.

[0165] Therefore, in this embodiment, the bus between each MAE and its respective hub may be the same width as the other buses in the streaming subsystem, enabling each MAE to support data rate X.

[0166] Please understand that X can be any suitable value. For example, X could be 200 or 400 Gb / s. Please understand that these values ​​are purely illustrative and may differ in different embodiments.

[0167] In some embodiments, the number of egress plugins supported by hub 256 may be twice that of other hubs. In both embodiments considered in relation to Figures 4a and 4b, the total bandwidth of the third hub may be twice the bandwidth of either the first hub 252 or the fifth hub 260.

[0168] In some embodiments, the data path effectively includes plug-ins. This may, in some cases, avoid the need to consider timing issues. The scheduler handles the timing of when plug-ins are provided. The scheduler is described in more detail below. As mentioned above, the hub may provide downstream buffering for upstream processors and plug-ins that wish to inject data into the stream. This may be controlled by the scheduler.

[0169] Alternatively or additionally, one or more components of the data path can be bypassed or replaced by a plug-in.

[0170] Plugins can be loaded dynamically; that is, plugins can be installed after the NIC has been installed.

[0171] A plugin can be any suitable component. For example, a plugin can be a hardware component. A plugin can be a hardware component of an accelerated application. A plugin can enable custom protocol and / or acceleration support.

[0172] Refer to Figure 5, which shows an example in which a plugin is used to add features to the data path in Figure 4a or Figure 4b. The streaming subsystem is as described in relation to Figure 4a or Figure 4b. In the example shown in Figure 5, the data path from the VNIC TX engine to the MAE244 is modified to include an encryption plugin 250 via a second hub 254. The data to be transmitted is passed to the encryption plugin 250 via the hub 254. The data is removed from the data path, encrypted by the encryption plugin, and then reinjected into the data path via the second hub.

[0173] The data path from the VNIC RX engine 208 to the MAE 244 is modified to include a decoding plugin 251 via a third hub 256. The received data is passed to the decoding plugin via hub 254. The data is removed from the data path, decoded by the decoding plugin, and then reinjected into the data path via the third hub.

[0174] In this example, the processed data is reinjected into the hub from which it is removed. However, in other embodiments, the data may be reinjected into the data path via a different hub.

[0175] These plug-in points on hubs 254 and 256 can be used for network layer encryption / decryption. Transport layer encryption (e.g., TLS) protocol plug-ins can use hubs 252 and / or 258. Some embodiments can use both network and transport layer encryption, utilizing plug-ins to these hubs. This latter embodiment can be used when double encryption or decryption is required per frame.

[0176] The encryption and decryption provided by the plugin may be IPSec encryption and decryption, or any other suitable encryption / decryption.

[0177] Refer to Figure 6, which shows an example in which a plug-in is used to replace components of the data path in Figure 4a or Figure 4b. The streaming subsystem is as described in relation to Figure 4a or Figure 4b. In the example shown in Figure 6, the MAE244 of the data streaming path is replaced by the custom engine 253.

[0178] The transmission path is modified as follows: Data transmission can be initiated by a host or application CPU providing one or more entries to one or more DMA transmission queues. The H2C DMA adapter interface 202 provides output to the VNIC TX engine 240 via the first hub 252. The VNIC TX engine 240 provides output to a custom engine via the second hub 254. The custom engine provides output to the NET_TX engine 208 via the third hub 256. The NET_TX engine 208 provides output to the transmit MAC 212. Thus, the data is purged and processed via one or more egress plug-ins on the second hub and reinjected into the data path via one or more ingress plug-ins on the third hub.

[0179] The receiving path may be as follows: Data from the network may be received by a receiving MAC 210 which provides output to the NET_RX engine 206. The NET_RX engine provides output to a custom engine 253 via a second hub 254. The custom engine 253 provides output to a VNIC_RX engine 242 via a third hub 256. The VNIC_RX engine 242 provides output to the C2H DMA adapter interface via a fourth hub 258. Thus, the data is filtered and processed via one or more egress plug-ins of the second hub and reinjected into the data path via one or more ingress plug-ins of the third hub.

[0180] As described above, some embodiments may use capsules. Refer to Figure 7, which shows capsules used in some embodiments. In some embodiments, the streaming subsystem carries the capsule. As will be discussed later, capsules may be used alternatively or additionally in other parts of the NIC. The capsule may be a control capsule or a network packet capsule. The payload may be provided by a pointer to the payload. Alternatively, the payload may be provided within the capsule.

[0181] As schematically shown in Figure 7, the capsule contains metadata 702, which may be provided at the beginning of the capsule. This may be followed by the capsule payload 710.

[0182] The metadata may depend on whether the capsule is a control capsule or a network capsule.

[0183] A network packet capsule contains capsule metadata, followed by, for example, an Ethernet frame within the payload.

[0184] Metadata may include a capsule header that is common to both control capsules and network capsules. The capsule header may include information indicating whether the capsule is a control capsule or a network packet capsule. The capsule header may include route information that controls the routing of packets through the streaming subsystem. The capsule header may include virtual channel information indicating the virtual channel used by the capsule. The capsule header may include length information indicating the length of the capsule.

[0185] A network packet capsule has a network capsule header followed by a capsule header as part of metadata 702. This can indicate the layout of the capsule metadata and whether or not the capsule payload contains an Ethernet FCS (frame check sequence).

[0186] The metadata of a control capsule may indicate the type of control capsule. A capsule may have metadata indicating an offset, which may indicate the beginning of the data being processed.

[0187] A scheduler can control the timing of data movement along a data path. A scheduler can also be used to control timing even when data is processed by one or more plugins. In some embodiments, each stage of the data path can be controlled by the scheduler. In some embodiments, plugins are scheduled by the scheduler.

[0188] In some embodiments, the scheduler may use a credit-based system.

[0189] The scheduler manages the data flow within the streaming subsystem. In some embodiments, this data flow includes a encapsulation.

[0190] A flow may have one source and one or more destinations. From a scheduler's perspective, the flow source and destination are memory resources that hold the data being sent, or space for the data being received. The destination may be one or more buffers within a downstream hub, and the source may be one or more buffers within the hub and / or its plug-ins.

[0191] A flow source communicates to the scheduler the amount of data it contains and wants to output. This flow source state is called the source credit count. Depending on the source type, the source credit may refer to one of the following: 1) The number of descriptors that are represented as state values. a) No descriptors available, b) The number of available descriptors is greater than zero and less than the globally configured threshold, c) The number of available descriptors is greater than the number of globally configured thresholds.

[0192] This can be used by a source that is an H2C DMA queue. 2) The number of capsules represented as state values. a) No capsules available, b) The number of available capsules is greater than zero and less than the globally configured threshold, c) The number of available capsules is greater than the globally configured threshold number.

[0193] This method can be used by the source, i.e., by the hub's FIFO.

[0194] In some embodiments, the amount of credit may, alternatively or additionally, refer to the amount of data measured in the bus transaction (e.g., a 512-bit word).

[0195] A flow destination can communicate to the scheduler the amount of free space available to receive data. This flow destination state may be called the destination credit count. Depending on the destination type, the destination credit may refer to one of the following: 1) The amount of data measured in a bus transaction (e.g., a 512-bit word). This can be used when the destination is a data buffer (e.g., a FIFO in a hub). 2) A two-state value indicating whether the destination can accept data. This may be used by a NET TX port or a NET TX port priority channel.

[0196] Based on the status of the flow source and flow destination, the scheduler determines which flows are eligible to transfer data. The scheduler evaluates all eligible flows according to its programming and determines which flows can proceed. For example, the scheduler may select the flow with the highest priority currently available and instruct the flow source to send a data block of a specific length (a scheduler job). The scheduler updates its internal state to better represent the state the system will be in when a job is completed. In this way, the scheduler may be able to issue another job request without waiting for already issued jobs to complete.

[0197] When the scheduler updates its state, it predicts the new state of the destination and the new priority relationships between flows. Because the scheduler may not accurately predict changes, it may take a pessimistic view, that is, it assumes the maximum amount of data that can be generated as a result of a scheduler job request and pushed to the destination. In some situations, the amount of data written to the destination may (sometimes significantly) exceed the size of the data block specified in the job request. There may also be scenarios where the amount of data is less than requested, or where no data is transferred at all.

[0198] The source executes job requests and sends a message to the scheduler for each completed job. This job response message may include cost, source status, and destination credits consumed. Cost informs the scheduler how much throughput resources the job consumed. Cost depends on the nature and character of the job. However, the cost function may be normalized so that the scheduler, which uses cost to update priority relationships between flows, can compare and evaluate the costs of different types of jobs. Source status is the new state of the source. Finally, destination credits consumed refer to the amount of destination space consumed by the data produced during the job.

[0199] The device shown in Figure 4a or Figure 4b has two source devices, which are a hub or a DMA adapter.

[0200] If the source is a hub, the source is the hub's FIFO, and the entity that executes the job request and generates the job response is the hub's read stage. In this device, the hub is followed by the engine and another hub. The next hub's FIFO is the destination. The engine can modify packets, thereby decreasing or increasing the length of each packet. The engine can create alternative or additional packets. The maximum amount by which the packet length can be increased may be a globally configured parameter. When reporting the consumed destination credits, the source hub read stage may assume that each packet in the job has been lengthened by the streaming engine by the maximum permitted amount.

[0201] The engine may create alternative or additional packets. The engine may delete alternative or additional packets.

[0202] When the source device is a DMA adapter, the source is a DMA queue, and the entity executing the job request is called the descriptor pipe. The descriptor pipe processes DMA descriptors and requests the DMA to read or write data from / to a host. The descriptor pipe processes the data. While processing the data, the descriptor pipe may resize packets due to TSO (TCP segmentation offload) operations, pseudo-header removal / addition, etc. When reporting the destination credits consumed, as in the case of a hub, the descriptor pipe may assume that each packet in the job has been lengthened by the descriptor pipe by the maximum possible amount.

[0203] For both source devices described, the entity resizing the job data (streaming engine or DMA adapter data pipe) may report a discrepancy between the destination credits consumed specified in the job response and the actual destination credits consumed. This can be achieved by sending a destination credit adjustment message for each processed packet. Each destination credit adjustment message communicates the difference between the maximum expansion scenario of the packet used in the job response and the actual size of the packet. Destination credit adjustment messages may be issued per packet.

[0204] When a source transitions from an empty state to one of two non-empty states, the source sends a source credit message to the scheduler.

[0205] Due to source-specific TX threshold settings, a source may be prevented from notifying the scheduler that it is no longer empty until other conditions are met. Therefore, a source credit message notification may inform the scheduler that the source has transitioned from an empty state to a non-empty state below the threshold state, or to a non-empty state above the threshold state.

[0206] The destination sends a destination credit message to the scheduler indicating an increase in the amount of space within the destination. In some embodiments, to ensure that the scheduler is not overwhelmed with destination credit messages, the destination may implement a destination credit message moderator that limits the rate of destination credit messages to a pre-configured maximum rate.

[0207] The scheduler issues a job request message to the source.

[0208] Once the job request is complete, the source issues a job response, which specifies the following: Source status: New state of source, empty, not empty below threshold, not empty above threshold. Destination credits consumed: A pessimistic estimate of the amount of destination credits consumed during job execution, and The cost of the job.

[0209] The engine or DMA adapter descriptor pipe provides a destination credit adjustment message for each processed packet. In some embodiments, to ensure that the scheduler is not overwhelmed with destination credit adjustment messages, the stream engine may implement a destination credit adjustment message moderator that limits the rate of destination credit adjustment messages to a pre-configured maximum rate.

[0210] In some embodiments, one or more sources may process several jobs in parallel (with at least some overlap).

[0211] Each of the schedulers in Figure 4a or Figure 4b is generally specialized in managing a related set of sources, destinations, and flows that link them together. The internal configuration and programming of the scheduler specify how flows relate to sources and destinations. In one embodiment, two flows may not share a source, but multiple flows may target the same destination, and some flows may target multiple destinations. QoS (policies) may be used by the scheduler to control the sharing of pipeline bandwidth on an interface.

[0212] Refer to Figure 8a, which shows a hub in several embodiments. The embodiment of this hub shown in Figure 8a has two egress plugins 902 and one ingress plugin 904.

[0213] Data may be received from upstream adapters and / or engines, depending on the location of the hub within the streaming subsystem. Alternatively or additionally, data may be received from ingress plugins.

[0214] The hub has a write controller (hub write stage (HWS) and plug-in hub write stage (PWS)). These are labeled HWS0, HWS1, and PWS in Figure 8a. Data from the upstream adapter and / or engine is provided to the hub write stage, and data from the ingress plug-in is provided to the plug-in hub write stage. The HWS may provide or may be a demultiplexer.

[0215] The hub comprises a read controller (hub read stage HRS) referenced in Figure 8a, and buffer memory blocks. These buffer memory blocks are referenced as Mem Block 0, 1, and 3 in Figure 8a. The buffer memory blocks may contain circular buffers, thereby abstracting the circular buffer implementation from the rest of the hub design. The buffer memory blocks may contain one or more circular buffers or any other suitable buffer implementation. The buffers of the buffer memory blocks may contain encapsulated data and / or metadata.

[0216] The data buffer memory blocks (Mem Blocks 0 and 1) may implement a FIFO that links the hub's ingress and egress ports. A shadow FIFO (provided by Mem Block 3) may be used to support ingress plug-in operation. The shadow FIFO may rate-match with the FIFO used to support egress plug-in operation.

[0217] A metadata buffer memory block may be implemented by a FIFO that carries metadata (capsule length and other fields), allowing the metadata (typically length) to be prefetched by the read stage so that it is written by the write stage at the end of the capsule but read by the read stage at the beginning of the capsule. The metadata FIFO may be provided within memory blocks Mem Block 0, 1 and / or 3.

[0218] The output of the HWS stage is provided to the egress plugin and / or data buffer memory blocks Mem Block 0 and 1.

[0219] The read controller HRS incorporates a scheduler destination credit message moderator, which is responsible for generating scheduler destination credit messages at a predetermined rate (notifying each scheduler of the presence of free space in the hub buffer).

[0220] The read controller also generates a source credit message (which notifies the scheduler of the presence of data in the hub buffer), as mentioned earlier.

[0221] The write and read stages can exchange read / write notification messages with each other. A point-to-point link for read / write notification messages is provided between read / write stages within the same hub. The notification message informs the receiving controller of each transaction performed by the controller producing the message, namely, which FIFO is being written to / from, the type of write / read transaction, SOP (start of packet), EOP (end of packet), and MIDDLE.

[0222] Using notification messages, each controller can track the state of all FIFOs it accesses, namely the number of words, the number of complete packets only, and the number of packets that have been read / written completely or partially.

[0223] The HRS stage is configured to receive packet notification messages from the ingress plugin. The HRS stage is also configured to provide local credits to the ingress plugin.

[0224] Each buffer memory block may hold one or more data buffers and associated metadata buffers. Each hub read or write port may have full ownership of at least one read or write buffer memory block port. In some embodiments, two hub ports may not share the same buffer memory block port. Any hub write-read port pair that wishes to pass data may have at least one buffer memory block in common.

[0225] This describes the scheduler. The scheduler is used to control HRS activity. One or more schedulers may control the read stages of other hubs and / or other blocks. The scheduler receives source credit messages from this hub and destination credit messages from one or more downstream hubs and / or one or more other blocks. The hub sends its destination credit information to one or more upstream schedulers. The HRS stages and schedulers exchange job request messages and job response messages as described above.

[0226] Refer to Figure 8b, which schematically illustrates the Ingress Plugin Interface integration. In the embodiment shown in Figure 8b, two hubs 900a and 900b are shown. Hub 900a is upstream of hub 900b. Each of the hubs may be as described in relation to Figure 8a. In this embodiment shown, the second hub 900b does not have a PWS and associated memory block. If the hub supports Ingress Plugin, a PWS and associated memory block may be provided. Otherwise, the PWS and associated memory block may be omitted, as in the case of the second hub 900b shown in Figure 8b.

[0227] Engine 916 is located between the hubs. This could be one of the engines discussed earlier.

[0228] The scheduler 918 may be as shown in Figure 8a and may receive source credits from the first hub. These source credits are received from the HRS of the first hub and relate to the FIFO of the first hub, as schematically shown in Figure 8b. The HRS of the first hub also provides the scheduler with job requests and / or job responses.

[0229] The HRS of the first hub also provides source credits for the ingress plugin 920. The ingress plugin may be provided by the programmable logic portion 912 of the NIC (e.g., programmable logic 113 in Figure 2a).

[0230] In some embodiments, the ingress plug-in itself may be provided with a hub 922. This plug-in hub may be called a soft hub in that it is provided within the programmable logic portion 912 of the NIC and may not be part of the enhanced portion 914 of the NIC. The enhanced portion 914 is schematically shown by a dotted line between the enhanced area and the programmable logic of the NIC.

[0231] Hubs 900a and 900b may be provided within the enhanced portion of the NIC. Plug-in hub 922 may have the same or similar structure as the second hub 900b, having an HWS portion, a memory buffer, and an HRS portion. Source credits may be provided by the plug-in hub and relating to the FIFO of plug-in hub 922.

[0232] Data provided by plug-in 920 is provided to the first hub 900a via the plug-in hub and a pair of converters 924a and 924b. The first converter 924a of the pair of converters is provided by programmable logic, and the second converter 924b of the pair of converters is provided within an enhanced portion of the NIC. Data is output from the plug-in hub to the first converter 924a, which converts the data into the format required for the first hub. This allows the data to be provided in the required bus format. The data is passed from the first converter 924a to the first hub via the second converter 924b. In some embodiments, the first converter provides a first conversion of the data, and the second converter provides a second conversion of the data into the format required for the first hub.

[0233] As just one example, the first converter converts the data to an ST bus format, which is clocked at, for example, 400MHz, and the second converter converts the data to an ICSB bus format, which is clocked at, for example, 800MHz.

[0234] The second converter receives FIFO credits from the first hub's PWS, which are provided to the plug-in hub via the first converter 924a.

[0235] In some embodiments, the converter may be omitted. In some embodiments, only one converter is required. In some embodiments, one or more converters function as an interface between the first hub and the plugin hub or the plugin itself.

[0236] Please understand that converter 924b may be considered part of the hub. Plugin 920, plugin hub 922, and the first converter 924a may be considered to provide an ingress plugin.

[0237] The scheduler is configured to receive destination credits from downstream hubs. The scheduler may be provided by computer code running on suitable hardware, which may, for example, be at least one processor and at least one memory.

[0238] Refer to Figure 8c, which schematically illustrates the egress plugin interface integration. In the embodiment shown in Figure 8c, two hubs 900a and 900b are shown as previously discussed. If each hub supports ingress plugins, a PWS and associated memory block may be provided. Otherwise, the PWS and associated memory block may be omitted.

[0239] Engine 916 is located between the hubs. This could be any one of the engines mentioned above.

[0240] The HRS of the first hub 900a provides job requests and / or job responses to the scheduler 918. The scheduler is configured to receive destination credits from the downstream hub 900b. The scheduler is configured to receive destination credits from the egress plug-in 920'.

[0241] The egress plugin 920' may be provided by user logic within the fabric indicated by reference numeral 912.

[0242] In some embodiments, the egress plugin itself may be provided with a hub 922'. This plugin hub is provided within the programmable logic portion 912 of the NIC, as discussed in relation to the ingress plugin.

[0243] The egress plug-in hub 922' may have the same or similar structure as the second hub 900b, having an HWS portion, a memory buffer, and an HRS portion. Destination credit may be provided by the plug-in hub for the FIFO' of the egress plug-in hub 922'.

[0244] The data provided to plugin 920' is provided by the second hub 900b via a pair of converters 924a' and 924b. This is controlled by the scheduler by the use of egress plugin destination credits. One or more rate-matching FIFOs may be used. The rate-matching FIFOs may match bus width, and therefore data rate. In some embodiments, one rate-matching FIFO may be provided for each egress plugin interface. This may allow transitions from full-width and half-width bus interfaces between the engine and the second hub to the egress plugin.

[0245] The first converter 924a' of the pair of converters is provided within the programmable logic portion of the NIC, and the second converter 924b' of the pair of converters is provided within the enhanced portion 914 of the NIC. Data is output from the second hub 900b and provided to the second converter 924a, which converts the data into the required format. This converted data can be passed to the first converter 924a', which can provide the data in the format required by the egress plug-in 922'. Data is passed from the second hub to the first converter 924a' via the second converter 924b'. In some embodiments, the second converter provides a first conversion of the data, and the first converter provides a second conversion of the data into the format required for the egress plug-in. As just one example, a second converter converts data from an 800MHz-clocked ICSB bus format to a 400MHz-clocked ST bus format, and then a second converter converts the 400MHz-clocked ST bus format into a data stream for input to the egress plugin.

[0246] In some embodiments, the converter may be omitted. In some embodiments, only one converter is required. In some embodiments, one or more converters function as an interface between the second hub and the plug-in hub or the plug-in itself.

[0247] Please understand that converter 924b' may be considered part of the second hub. The egress plugin 920', the egress plugin hub, and the first converter 924a' may be considered to provide the egress plugin.

[0248] The scheduler is configured to receive destination credits from the downstream hub.

[0249] The scheduler may be provided by computer code that runs on suitable hardware. The hardware may, for example, be at least one processor and at least one memory.

[0250] The cache subsystem shown in Figure 4a or Figure 4b may be used by the MAE in some embodiments. The cache subsystem may comprise a cache counter, a lookup service, and multiple cached CAMs. In the embodiment shown in Figure 6, the MAE is bypassed by a custom engine. This is one embodiment in which the cache subsystem is not used by the streaming subsystem. In some embodiments, the cache memory may be modified for a specific purpose. For example, in some embodiments, the memory may be used as one or more of FIFO (first in first out), BCAM, or STCAM.

[0251] In some embodiments, access to memory is performed via the fabric or via the NoC. The CAM may be designed to cache so that misses are transferred via the NoC to a miss handler implemented on the fabric. The miss handler can "extend" the CAM using any suitable memory, such as on-chip memory or external DDR (double data rate) memory.

[0252] If memory is repurposed, the streaming subsystem can no longer access the cache subsystem.

[0253] Therefore, some embodiments may allow the cache to be reused as a CAM when it is not being used as an enhanced cache to support the MAE engine.

[0254] In this regard, refer to Figure 9, which shows the modified cache subsystem 215. In some embodiments, x memory 800s may be provided. As just one example, there may be 32 memory 800s. In this embodiment, the memory may be 64b wide. However, this is just one example. Each memory 800 may be associated with a dual port 802. Each port 804 and 806 may support reading and writing.

[0255] In this embodiment, there may be 800M accesses per memory, which can give a total bandwidth of 1638 Gbit / s. In some embodiments, this may support any required combination of reads and writes.

[0256] In some embodiments, the cache memory can be modified to suit the application. For example, the memory may be used to provide one of the following: 4x 200Gbit / s FIFO 8x BCAM with 64b key + value and 800M lookup / s 1x STCAM, 4 masks, 256b key + value and 400M lookup

[0257] In some embodiments, an on-top addressing scheme is provided in which buffers in the cache can be allocated, deallocated, and referenced by address. Buffer addresses can be used as source / target for DMA and / or accelerator commands. Memory multiplexing is used to implement the CAM within a set of memory channels, each channel having a read / write controller. When this mode is active, memory may not be used as CAM simultaneously.

[0258] The aforementioned streaming subsystem may omit one or more of the aforementioned engines and / or include one or more other engines. One or more functions provided by one or more of the aforementioned engines may be omitted. One or more other functions may be performed by one or more of the aforementioned engines.

[0259] In some embodiments, data may cross a barrier one, two, or more times between the ASIC (enhanced portion) providing the streaming subsystem and the PL (Plugin) providing the plug-in. In some embodiments, data may be received from the network and terminate completely after leaving the streaming subsystem pipeline. In some embodiments, data may be supplied by the PL.

[0260] A plugin may be provided with one or more of the following: an ASIC, a CPU, and / or programmable logic. A plugin can be a data processing entity.

[0261] In some embodiments, the processing engine can be programmed to provide the required functionality. The processing engine can be programmed using any preferred programming language, such as RTL, C, P4, and eBPF.

[0262] Refer to Figure 16, which illustrates a method in several embodiments. This can be performed within a network interface device.

[0263] This method includes, in step 1601, receiving data in the first hub from a first upstream data path entity and from a first data processing entity implemented in programmable logic.

[0264] This method includes, in step 1602, controlling the output of data from the first hub to the first data processing engine by a first scheduler associated with the first hub.

[0265] This method includes, in step 1603, processing the data received from the first hub by a first data processing engine, and This method includes, in step 1604, outputting the processed data to a second hub by the first data processing engine.

[0266] Refer to Figure 10, which shows a NIC 109 having two CPUs 750 and 752. In practice, the CPUs may be a CPU complex. A CPU complex comprises a given number of CPU cores having their CPU caches and interconnections. The first of these CPUs 752 may be a host CPU. The second of these CPUs 750 may be an application CPU running an embedded operating system and / or application 728. Firmware 724 may provide control plane functionality for the NIC. The firmware may reside on a low-power CPU such as a reconfigurable processing unit (RPU). This is called the control plane CPU 724.

[0267] In some embodiments, CPUs 750 and 752 are provided by separate CPUs. In other embodiments, these CPUs may be provided by a common CPU. In some embodiments, one or both of these CPUs may be provided as part of a NIC. In other embodiments, one or both of these CPUs may be provided by a host device. In the example shown in FIG. 10, the two CPUs are separate CPUs. The first CPU is the host CPU 752, and the second CPU is the CPU 750 provided as part of the NIC.

[0268] The control plane CPU 724 may be separated from the CPU. In some embodiments, the control plane CPU may be provided as part of the second CPU 750. The control plane CPU 724 may be part of the NIC. However, in some embodiments, the control plane CPU may be at least partially implemented within the host.

[0269] As previously discussed, a stream of data is received / transmitted by the NIC. A stream of data may be received from the network or transmitted onto the network. Different streams of the data stream are associated with different flows. Different flows can be identified, for example, by IP address, socket, and port number.

[0270] The NIC may have several different streaming kernels provided by respective modules. A streaming kernel can process the received data. A streaming kernel can pass the processed data to the next streaming kernel. This will be discussed in detail later.

[0271] Data received from the network may be received by the MAC module 114. The MAC module performs MAC layer processing on the received data. The MAC module provides an output to a virtual switch as described above. The output may include the MAC processed data.

[0272] MAC-processed data is processed by the virtual switch portion (vSwitch) 102 of the NIC. The virtual switch may be provided by at least part of the aforementioned streaming subsystem. The processing performed may depend on the plugin used. The processing may be as described above. When the vSwitch has processed the data, it may provide output to the AES (Advanced Encryption Standard) module 730. The output may include the processed data.

[0273] When the AES (Advanced Encryption Standard) module 730 receives output from the vSwitch, AES may be configured to decrypt the processed data. In response to performing decryption, the AES module may provide output to the TCP module 766 or the kernel. The output may contain the decrypted data.

[0274] It should be understood that in some embodiments, at least some of the AES functions may be provided by plugging into the vSwitch.

[0275] This embodiment references the AES security function. It should be noted that this security can be any other suitable security function, such as ChaCha20-Poly1305 or Salsa20 and / or similar. The security function may implement a cryptographic algorithm to determine encrypted data or derive a key, and / or enable processing of custom network protocol headers. In some scenarios, the security function may be omitted.

[0276] In some embodiments, an intermediate module may be provided to analyze the data and determine which blocks and keys should be used for AES calculations. This intermediate module may be provided as a plug-in to the vSwitch.

[0277] The TCP module 766 is configured to perform necessary TCP-related processing on the decoded data, such as processing the TCP header, in response to its output from the AES module. In other embodiments, different protocol modules supporting protocols other than TCP may be provided, either alternatively or additionally.

[0278] In some embodiments, the TCP module 766 may perform all necessary TCP protocol processing. In other embodiments, the TCP module may be omitted, and TCP processing may be performed elsewhere. In some embodiments, the TCP module may perform only a portion of the TCP processing. For example, the TCP module may only perform reassembly and forward the header to a software TCP implementation. This may be provided, for example, by an accelerated network stack such as Onload, which the applicant provides on the application processing unit. This will be discussed later.

[0279] The TCP module may be provided by a plug-in and / or by one or more of the streaming subsystem's engines. This may depend on TCP-related processing performed on the NIC. As mentioned above, all or part of the TCP processing may be performed within the NIC, or no TCP processing may be performed within the NIC.

[0280] Depending on the context or address associated with the data, the TCP module provides output to either the key-value KV module 736 or the NVMeOF (non-volatile memory express over fabrics) module 734. This output provided by the TCP module may contain protocol-processed data. Please note that the KV module 736 and the NVMeOF module 734 are two embodiments of different modules that may be provided. However, please note that one or more other modules may be used instead of one or more of these exemplary modules. In some embodiments, there may be more than two modules or only one module. This may depend on the number and / or type of applications being supported.

[0281] In this embodiment, the KV module and the NVMeOF module are downstream of the TCP module in the receiving direction. In other embodiments, one or more modules may be provided in parallel with the TCP module and / or upstream of the TCP module in the receiving direction.

[0282] In some embodiments, one or both of the KV module and the NVMeOF module may be provided as plug-in modules to the streaming subsystem.

[0283] In some embodiments, the default is to provide output to one of the modules unless the data is associated with one or more specific data flows. In this embodiment, the default module may be the NVMeOF module 734, and only data associated with one or more specific data flows is provided to the KV module 736. Specific data flows may be identified, for example, by their address information.

[0284] In other embodiments, both modules may be associated with their respective data flows, and data is output to each module only if the data is associated with their respective data flows. In some embodiments, a given data flow may be directed to only one module. However, in other embodiments, a given data flow may be directed to two different modules.

[0285] The interface between the TCP module and the KV module is designed to provide output only for data associated with one or more specific data flows from the TCP module to the KV module. This interface will be discussed in detail later. Similarly, the interface between the TCP module and the NVMeOF module is designed to provide output only for data associated with one or more specific data flows from the TCP module to the NVMeOF module.

[0286] The NVMeOF module 732 performs its function on protocol-processed data in response to output from the TCP stack and provides output to the NMVe stack 742 in the first CPU 752 via an NVMe queue pair that supports the OS stack 734 in the NIC. This NVMe queue pair that supports the OS stack 734 may be provided by one or more vNICs in the PCIe functionality as described above, or it may be provided as part of the NVMeOF module 732.

[0287] This output to the NVMe stack 742 may contain data processed by the NVMeOF module 732. The NVMe stack 742 provides the output to the associated application 720 in the first CPU, which is the host CPU.

[0288] The KV module 736 provides an output to the SHM shared memory interface 738. The SHM interface 738 can be provided by one or more vNICs in the PCIe function as described above, or can be provided as part of the NVMeOF module 732.

[0289] The output is provided to the KV application 722 via the SHM interface and API 740. The API 740 can be provided by a runtime library. The API 740 and the KV application 722 can be provided on the first CPU.

[0290] In some embodiments, the applications 720 and 722 can be supported by different CPUs.

[0291] In some embodiments, the processing provided by the module can change the type of data. For example, the output from the vSwitch is a data unit corresponding to layer 2, 3 (Ethernet frame + IP processing) processing. The output from the TCP stack module is a reliable ordered byte stream. The output from the NVMeOF module can be an NVMe block storage level transaction. The post-TCP byte stream can be interpreted as a get request or a set request by the KV application.

[0292] It should be understood that the memory locations accessible by a given process or context (address space on the CPU) depend on the privilege level associated with that process or context. Different applications supported by the CPU can be associated with different address spaces. The address space of an application can depend on the privileges of that application.

[0293] The previous discussion concerned the processing of data received by the NIC. Applications may, alternatively or additionally, be configured to place data on the network. Data may be read from its respective memory location. This memory location may reside within the address space associated with each application. It should be understood that data may, alternatively or additionally, be messages. For example, a message may be a request message, a response message, a query message, or any other suitable message.

[0294] Data from the NVMe application 720 is passed to the NVMeOF module 732 via the NVMe stack 742 and the NVMe QP support OS stack 732. These entities process the data as needed. The processed data may be output to the TCP module 766.

[0295] Data from the KV application 722 is passed via API 740 and SHM interface 738 to the KV module 736, which processes the data as needed. The processed data may then be output to the TCP module 766.

[0296] TCP module 766 receives data from NVMeOF module 732 and / or KV module 736. In some embodiments, TCP module 766 may be configured to accept data from a given one of those modules only if that data is associated with one or more specific data flows. This will be described in detail later.

[0297] The TCP module 766 is configured to perform the necessary TCP-related processing on data received from either the KV module 736 or the NVMeOF module 732. The protocol-processed data is output to the AES module 730.

[0298] The AES module 730 may be configured to encrypt the received data. The AES module may output the encrypted data to the vSwitch 102. The AES module itself may be wrapped by a module for performing the protocol analysis necessary to determine data blocks and main material from network header information, and vice versa.

[0299] The vSwitch can process encrypted data. The processing provided by the vSwitch may depend on the NIC plug-in. One or more of the NIC modules shown in Figure 10 may be provided as plug-ins to the streaming subsystem, as described above.

[0300] The vSwitch is configured to output processed data to the MAC module for MAC processing. The data may reside on the network.

[0301] The vSwitch may be described above, for example, as shown in Figures 4a and 4b. However, in other embodiments, any other suitable NIC device may be provided. That NIC device may not have the functionality to support one or more plug-ins as described above.

[0302] The network management controller NMC726 may be provided by the control CPU 724. NMC762 is configured to control which data flows are processed by which modules. The NMC programs the modules to ensure that only data flows within their respective address spaces are processed by a given module.

[0303] In some embodiments, the NMC762 controls the steering of different flows within the NIC.

[0304] In some embodiments, different end users may require different applications to be supported by the NIC. As previously mentioned, NVMe and KV applications are examples of applications that may need to be supported. Other embodiments may, alternatively or additionally, support one or more other applications. Different applications may require that one or more modules, respectively, be supported, and / or that one or more hardware parts of the NIC be allocated to support a particular application. The allocation of resources required to support an application is controlled by the NMC726. Resources allocated to a particular application may remain separate from resources allocated to other applications and / or other resources required to support different functions such as protocol functions and encryption / decryption functions.

[0305] In some embodiments, hardware resources may be provided at least partially by programmable logic.

[0306] One or more hardware resources may be dedicated to a specific application, for example, as described above. Alternatively or additionally, one or more hardware resources may be shared by two or more applications. An example of a shared resource is memory, where all physical access is performed via a memory controller. In the case of shared resources, allocation is based on hardware regions or slices (ranges of addresses), and / or one or more other properties that may be required, such as bandwidth or priority. All shared and dedicated resources together can be considered as an address space.

[0307] One or more of the modules discussed earlier can be dynamically loaded by the NMC.

[0308] A module can be hardware on a NIC that implements hardware-accelerated application functionality. As mentioned earlier, kernels can be provided by each module and can be application-specific as they implement application functionality, and applications can potentially differ. A module can be associated with multiple kernels in some embodiments.

[0309] The functionality could belong to a user-space application. For example, such functionality could be a key-value database.

[0310] The functionality could belong to an operating system application. For example, a firewall could be one such functionality.

[0311] The functionality could belong to a hypervisor-resident application. For example, such functionality could be a virtual switch.

[0312] The hardware kernel provided by each module must mirror the same isolation / privilege properties of one or more of its respective functions, as discussed above.

[0313] The interface between the application and the kernel may be provided by a shell-like interface or any other preferred interface. In some embodiments, this interface may be implemented by a combination of firmware and hardware that provides a software API to the kernel and a hardware API for the kernel. This interface may be provided by an isolated circuit. This isolated circuit may be provided by a combination of firmware and hardware. The interface provided may depend on the operating system technology used by the NIC. The interface may be thought to be associated with a hardware address space. This hardware address space may comprise one or more of programmable logic, DDR, and CPU. The kernel connects the application to the hardware on the NIC (via the interface).

[0314] The kernel can be loaded into an area of ​​memory. As mentioned earlier, a module may have one or more kernels and their respective interfaces. This area of ​​memory can be protected from access by application programs at least. The kernel performs tasks such as executing processes, managing the hardware necessary to support applications, and handling interrupts. The required hardware may be the CPU, memory, peripheral devices, and / or the programmable logic of the NIC. The hardware resides within the shell's hardware address space.

[0315] The application runs on the host (first) CPU.

[0316] In some embodiments, loadable kernels can be inserted and removed at runtime. The kernel can be any preferred type of kernel. In some embodiments, the kernel can be a function (component) of an application compiled to run in hardware.

[0317] Different kernels may be associated with different privilege or trust areas. Different trust areas may be configured for different data flows / applications. This makes it possible to isolate different address spaces from each other. Different address spaces or flows may be associated with different hardware resources on the NIC, and these different hardware resources are isolated from each other. Kernels supporting different applications may be associated with different interfaces.

[0318] In the device shown in Figure 10, three different trust or privileged areas are indicated by dotted lines, with reference to 751a, 751b, and 751c.

[0319] The vSwitch, AES, TCP, and NVMeOF modules may be associated with the first trusted area 751a. This means that this area is associated with the first privileged domain.

[0320] The KV module, KV application, SHM, and API are associated with the second trust area 751b. This means that this area is associated with the second privileged domain.

[0321] The NVMe stack and associated applications may be associated with a third trusted area 751c. This means that this area is associated with a third privileged domain.

[0322] Generally, the second and third areas are kept separate from each other so that data cannot be pushed from one of the second or third trust domains to the other.

[0323] Therefore, in some embodiments, different privilege or trust areas or domains are provided to different data flows and / or applications. These different privilege or trust areas can be thought of as being associated with one or more modules. In the embodiments described above, interfaces may be provided by modules. In some embodiments, common interfaces may be shared by one or more modules.

[0324] Refer to Figure 11. Figure 11 shows the first Trust Area (AOT), AOT A, and the second AOT, AOT B. Please note that the trust areas are isolated from each other. In this embodiment, each trust area is associated with its own address space. Each of these trust areas is provided within the NIC.

[0325] In this embodiment, there is no overlap in the address spaces associated with each trust area. Each trust area may be associated with a given privilege level. The privilege levels may be the same or different. If hardware resources such as memory are shared between trust areas, the resources may be divided such that only the portion accessible by each trust shell or area is visible (and accessible) to that trust shell or area. Hardware within one trust shell or area has no knowledge of or access to hardware (wires, logic, etc.) within a different trust shell or area. This can extend to debugging and / or diagnostic tools, and the software compiler used to generate and link one or more kernels of this hardware and trust area.

[0326] Resource usage is shared according to system policies. In the CPU, for example, the MMU (memory management unit) may perform this memory virtualization function. In the NIC, applications and associated hardware kernels can be dynamically created, and therefore, a single hardware element cannot virtualize all possible combinations of trust areas.

[0327] In some embodiments, the address space can be shared. This may require the existence of resource-specific protections to enforce privileges (such as an MMU for shared physical memory).

[0328] In some embodiments, the address space within the NIC can be controlled by the NMC726.

[0329] The address space of the trusted area may encompass one or more accelerator engines, the programmable logic of the NIC, and / or local memory.

[0330] At runtime, a communication channel is created between two trusted areas. This communication channel can be a bus or a similar communication channel. As just one example, the communication channel could be an AXI-B bus. The bus is referred to as 'a'.

[0331] Once a communication channel is created, isolation circuits are set up. Each trust area is provided with the interfaces described above. AOT A has interface A, and AOT B has interface B. Each of these interfaces is provided with its own isolation circuit. This isolation circuit may provide functionality similar to that provided by the system call handler function. For example, this functionality may check data validity and / or handle lower-level issues such as unexpected bus transaction terminations when a module is reset or removed. The functionality provided by the isolation circuit depends on the relative privileges associated with each trust area. System call handler-type functionality effectively enables interaction between applications and kernels. One kernel in one trust domain cannot directly read from and write to the address space of another kernel in a different trust domain.

[0332] Once the isolation circuit is set up, kernel logic corresponding to each address space is loaded. This is referred to as c. This kernel logic can be associated with one or more kernels. The isolation circuit can be associated with one specific module or kernel of the trust area. This could be the entry point module and / or exit point module of the trust area.

[0333] The isolation circuitry provided may depend on the relative privileges associated with each trust area. Refer to Figures 12a and 12b for further details.

[0334] In Figure 12a, AOT A is associated with lower privileges than AOT B. This corresponds to the embodiment in Figure 10, where AOT A comprises the KV kernel and AOT B comprises the vSwitch, AES kernel, TCP kernel, and NVMeOF kernel. In this case, control or master isolation circuitry may be provided within AOT B. In particular, the interface with AOT A may be the TCP kernel via the created communication channel. Isolation circuitry may be provided to ensure that only data associated with specific flows that should be directed to the KV kernel are actually directed to the KV kernel. Isolation circuitry may be provided between the TCP kernel output and the bus. In some embodiments, isolation circuitry may be integrated into the kernel.

[0335] Alternatively or additionally, the isolation circuit may cause any unwanted data flow from AOT A to be discarded.

[0336] In some embodiments, isolation circuits may be provided within each AOT to address hardware-level issues when a module is removed / reset. This can occur on either side regardless of privilege. This kernel removal or insertion can be performed at any time as needed. In other words, the kernel can be inserted or removed while the system is running.

[0337] In Figure 12b, AOT A is associated with the same privileges as AOT B. In this case, the isolation circuits provided within AOT B and AOT A are of equal weight. Isolation circuits within AOT B may be provided to ensure that only data associated with a particular flow that should be directed to kernel A is actually directed to kernel A. Isolation circuits within AOT A may be provided to ensure that only data associated with a particular flow that should be directed to kernel B is actually directed to kernel B.

[0338] Alternatively or additionally, isolation circuits within AOT B may cause any unwanted data flows from AOT A to be discarded. Alternatively or additionally, isolation circuits within AOT A may cause any unwanted data flows from AOT B to be discarded.

[0339] Isolation circuits can enforce data values, such as header bits (e.g., IP source address bits), to ensure they are correct. This isolation circuitry enforcing the data values ​​may be located within a confidence area that outputs and / or receives the data values.

[0340] Isolation circuits associated with a particular trust area may modify the data received by that trust area to a format used by that trust area. Isolation circuits associated with a particular trust area may modify the data output by that trust area to remove portions of the data required only within that trust area.

[0341] The isolation circuits used by each trust area may be configured to add and / or remove data, such as encapsulation used only within the privileged domain of that trust area.

[0342] Isolation circuits can enforce proper adherence to bus protocols. This could be, for example, on links between trusted areas. For instance, isolation circuits can ensure that AXI transactions terminate properly if, for example, one side is reset or removed and / or is within limits (length).

[0343] Alternatively or additionally, isolation circuits can ensure that credit-based flow control and scheduler interfaces function correctly. Depending on the specific operating environment of the trust area, enforcement by isolation circuits may be optional.

[0344] Therefore, when a kernel is loaded onto a NIC, one or more hardware linkers or communication links are provided to connect the kernel to other kernels. These hardware linkers ensure that only data associated with authorized network flows can be received and / or output. Kernel loading makes one or more hardware resources addressable to a given address space.

[0345] The address space associated with a given application may include the address space provided by the NIC. Different address spaces are associated with different applications. Different trust areas may prevent one application from accessing resources associated with a different application. Address spaces can be dynamically constructed relative to a given application address space / trust area. Address spaces may include CPU resources. Therefore, trust areas can be considered an extension of the CPU address space structure used to provide isolation for software applications running on the CPU. Thus, trust areas can provide isolation for hybrid hardware and software applications running on different hardware combinations, including the CPU.

[0346] Please understand that data plane accelerator functions such as the AES module and vSwitch can be logically represented as streaming kernels. These kernels are considered to be part of the same trust area as the TCP kernel and are provided within the same trust area.

[0347] The NMC726 can provide software-defined networking on a NIC that defines capsule routing via the kernel topology. Each capsule is associated with a network flow, and the capsules are routed according to their associated network flow. The capsules can be as described above.

[0348] The NMC726 is configured to allow NIC hardware to be used by different trust areas. The hardware used by each trust area comprises one or more of the following: fabric (reconfigurable logic), accelerators, network interfaces, and CPUs (embedded and / or external). The NMC is configured to provide different protection domains or trust areas. The control plane includes runtime functions, which control the dynamic loading of the kernel as described in relation to Figure 10.

[0349] In this embodiment, a TCP module common to both applications is provided. In other embodiments, the TCP module is provided to each application.

[0350] The AES module may be omitted in some embodiments. In other embodiments, one or more different cryptographic modules may be used instead.

[0351] The modules shown in Figure 10 are just examples. In other embodiments, one or more modules may be omitted. One or more alternative modules may be provided. At least one shared module may be shared by two or more applications in different trust domains, and / or at least one dedicated module may be dedicated to one or more applications in the same trust domain. One or more dedicated modules may be closer to the application than one or more shared modules in the data path.

[0352] A module can be thought of as a set of NIC hardware resources configured to provide module functionality. This may be for providing the kernel. These resources may be one or more of the following: fabric (reconfigurable logic), accelerators, network interfaces, and CPUs (embedded and / or external). As just one example, a module may be provided by programmable logic or by any other suitable hardware. In some embodiments, a module may be provided by configurable hardware. A module may be configured to execute computer code to provide the module's required functionality. A module may have memory or have access to memory. That memory may store, for example, computer code.

[0353] In some embodiments, a dedicated module may be shared by two applications, in which case those two applications share the same trust domain.

[0354] A shared module can serve two or more different trust domains, each of which is associated with one or more applications.

[0355] In the embodiments described above, one or more kernels or modules are provided to the streaming subsystem by a plug-in. It should be noted that in other embodiments, the streaming subsystem architecture described above may not be used. In these latter embodiments, modules may be provided in a streaming receive path for incoming data and / or a streaming transmit path for transmitted data. Such streaming paths may include one or more of the engines described above. However, in embodiments where the streaming paths can be constructed to process data sequentially, hubs and their associated schedulers may be omitted.

[0356] In other embodiments, FPGAs (or other programmable logic) may support service scenarios. For example, one trust area may include monitoring and billing for an infrastructure provider as well as private networking, while another trust area may include all other hardware resources.

[0357] Refer to Figure 17, which illustrates a method in several embodiments. This can be performed within a network interface device.

[0358] The method includes, in step 1701, linking a first trust area and a second trust area, wherein the first trust area includes a first portion of a network interface device, the first portion includes a first kernel, and the second trust area includes a second portion of a network interface device different from the first portion, the second portion includes a second kernel.

[0359] This method includes, in step 1702, using an isolation circuit associated with the first trust area to control the data passed between the first trust area and the second trust area.

[0360] In the following embodiments, Ceph is used as an example of a data storage platform. It should be understood that Ceph is one embodiment of a data storage platform, and that embodiments may be used with any other suitable data storage and / or management platform or application. Other embodiments may, alternatively or additionally, use NVMe or distributed object store applications.

[0361] In storage virtualization, the guest OS can make requests. These requests may be virtio-blk (block) requests. These requests may be read or write requests. These can be handled by the SPDK (storage performance development kit) BDEV (block device) plugin for Ceph, or other suitable functions.

[0362] Virtio devices are provided in a virtual environment but appear as physical devices to guests with virtual machines. This allows the guest OS to use standard drivers. Virtio-blk is one embodiment of a virtualized storage backend, and in other embodiments, Virtio-SCSI may be used. In other embodiments, non-Virtio devices and non-Virtio virtualized storage backends may be provided.

[0363] SPDK provides a set of tools and libraries for writing scalable user-mode storage applications. SPDK allows all necessary drivers to be moved into user space, thereby avoiding system calls and enabling zero-copy access from applications. The SPDK block device layer, BDEV, is a C library intended to be equivalent to the operating system block storage layer, which often sits directly above device drivers in the traditional kernel storage stack. This library may provide a pluggable module API for implementing block devices that interface with block storage devices. In other embodiments, other tools and libraries may be used instead of SPDK.

[0364] The Ceph function serves requests over the network using one or more other Ceph nodes. This can be done using the MSGR protocol (a low-level protocol through which messages are delivered by Ceph) via TCP sockets. The host TCP stack can send network requests and receive responses from one or more remote Ceph nodes. The Ceph function processes the responses and completes the SPDK BDEV request. The Virtio-Blk driver can deliver the read data to the guest OS, for example, if the request was a read request.

[0365] Refer to Figures 13 and 14, which illustrate the support for storage virtualization by the NIC. The NIC may be as described above.

[0366] Some embodiments can facilitate handling of data rates that may exceed the CPU's processing capacity.

[0367] In some embodiments, control and data handling can be separated. The data payload and header can be handled separately.

[0368] In some embodiments, the payload data is written to memory such as DDR. This may be the memory of the NIC, or it may be separate from the NIC.

[0369] The processing of control data (e.g., protocol processing) can be done in software, while the handling of data can be done in hardware.

[0370] In some embodiments, capsules as described above may be used.

[0371] Figure 13 shows a NIC 109 configured to support storage virtualization. The NIC may be at least partially as described above. The NIC 109 has one or more MAC layer functions 114. The virtual switch function 102 is configured to receive data from and / or provide data to the MAC, as described above. A TCP module 766, as described in relation to Figure 10, may be provided. The TCP module 766 may receive data from and / or provide data to the virtual switch function 102. The TCP module may process the data as described above.

[0372] Ceph module 768 is provided.

[0373] The Virtio-Blk (block) module 772 is provided. The Virtio-Blk 772 is a DMA adapter. It presents a standard PCI hardware personality and supports DMA ring compliant with the Virtio standard, allowing software on the CPU 752 to issue Virtio commands to the NIC.

[0374] The Ceph module 768 and Virtio-Blk772 are described in more detail. These modules can be implemented in hardware. In some embodiments, these modules handle the data plane. One or both of these modules can be implemented as plug-ins.

[0375] The NIC109 is provided with DDR memory 770 or any other suitable memory.

[0376] A host CPU 752 as described above may be provided. The host CPU may have DDR 762 (or other suitable memory) and a virtual machine 764.

[0377] The second CPU 750, provided by the NIC device or host, may be equipped with DDR 760 (or other suitable memory). This may be the same as or different from DDR 770. This may be the same as the second CPU considered in relation to Figure 10.

[0378] The second CPU comprises a Ceph client 754, a network stack library 756, and an SPDK library 751. The network stack library 756 and the SPDK library 751 are linked to the Ceph client in user space. The network stack library provides a socket interface with Ceph. The SPDK library provides a BDEV interface with the Ceph client.

[0379] The SPDK library includes Virtio-Blk software feature 758, which recognizes the Virtio-Blk hardware 772 and allows the use of DMA pointers for non-CPU coherent data (payloads stored in DDR 770, which will be discussed later).

[0380] There may be performance advantages to not using the host operating system kernel for TCP and Virtio-Blk functionality.

[0381] The network stack library 756 may be the Onload network stack library provided by the applicant, or any other suitable network stack client operating at the user or application level. The Onload library is provided at the application level to enable handling of protocol modes at the user level without the involvement of the operating system. In other words, operating system kernel bypass is supported. The network stack library may support any suitable protocol. In some embodiments, the network stack may support TCP and / or UDP over IP and / or any other suitable protocol. In the embodiments shown in Figures 13 and 14, the Onload library supports TCP function 757.

[0382] Refer to Figure 14, which provides a more detailed view of the aspect of Figure 13 that uses the handling of Ceph read responses as an example. In Figure 14, a portion of the NIC of Figure 4a is schematically shown together with the first egress plug-in 790 and the second ingress plug-in 792. In other embodiments, the NIC of Figure 4b may be used.

[0383] The first plugin, 790, provides an interface to the network stack provided at the user level. This first plugin may be the Onload TCP RX plugin. This may correspond to TCP module 766. This plugin is an egress plugin and originates from hub 256. This may be considered a packet processor.

[0384] The second plugin could be a data storage plugin. For example, the second plugin could be a Ceph plugin. The second plugin is an ingress plugin and provides input to hub 258. This plugin could correspond to Ceph module 768, which can be considered a packet processor.

[0385] A data flow or connection may receive a stream of data packets for a data storage application (Ceph in this example). A packet may include a header and the data to be stored. In this example, the data is provided in response to a read request. The header may include a Ceph header and a TCP header (or other transport protocol headers).

[0386] The data is received by the fifth hub 260 from the network receive port streaming engine and directed to the MAE 244 via the second hub 254. The MAE 244 then directs the data to the first plug-in via the third hub 256.

[0387] The first plugin may process the packets and obtain the TCP header portion. The first plugin also ensures that the data being provided is in order. The first plugin presents the data storage plugin 792 with an ordered byte stream. The data storage header may appear anywhere in the byte stream (not just at the beginning of the IP segment). If the data does not arrive in order, the output to the data storage plugin may include the entire network frame and an instruction that the data does not contain any application data to be processed.

[0388] The first plug-in 790 passes the packet to the data storage plug-in 792. The data storage plug-in separates the data storage application header from the protocol header. For example, the protocol header could be the TCP header. The data storage plug-in outputs the separated headers to the hub 258. The fourth hub directs the TCP header to the TCP header ring of the network stack and the data storage application header to the packet payload ring of the network stack. The data storage plug-in directs the packet's data directly to memory. The data storage plug-in also provides a pointer to the data storage application header in the packet payload ring of the network stack. The pointer points to the location of the data in memory 770.

[0389] On the second CPU, Onload client 756 has a TCP header ring associated with TCP state control. This receives TCP headers from hub 258. The Onload client also has a packet payload ring used to manage Ceph headers and data pointers to the location of data in memory. There is also a reinjection ring with TCP reinjection control. This is used when packets are not in order and one or more packets need to be reinjected to put the packets in the correct order.

[0390] At the user level, on CPU 750, the SPDK provides the Virtio-Blk software function 758 and a BDEV interface that interfaces with the Ceph client 754. BDEV is a library for Ceph's block storage components. The Ceph client 754 can communicate with Ceph storage. The Ceph client 754 can communicate with remote storage or other Ceph nodes via a socket interface provided by the Onload client. In some embodiments, the Ceph application runs in a different operating system than the application making the block storage request. The Ceph application accesses the network via a user-space network stack, e.g., Open Onload. The Ceph application accesses its local storage via a user-space storage stack, e.g., provided by the SPDK. Upon access by the Ceph application, data is transferred via DMA through the SPDK.

[0391] This section describes the processing of Ceph read response packets. It should be understood that the read operation is initiated by a virtio-blk read request generated by VM 764, using the virtio-blk772 hardware interface, which is received by the virtio-blk758 software issuing the BDEV.read API call. Ceph client 754 had issued a network TCP socket write to another Ceph node to request data. The returned data (read response) is the point highlighted in the example in Figure 14.

[0392] The Ceph read response packet is received by the fifth hub 260 from the network receive port streaming engine and directed to the MAE 244 via the second hub 254. Note that the data is transmitted in the capsule described above. The Ceph receive response includes the Ceph read data, Ceph header, and TCP header. The MAE 244 directs the data to the first Onload plugin 790 via the third hub 256.

[0393] As can be seen from Figure 14, the first plugin receives the Ceph read response. The first plugin can process the TCP header of the Ceph response.

[0394] The first plugin provides output to the Ceph plugin. The Ceph plugin writes the Ceph read data directly to the DDR. The output is also provided to hub 258 by the Ceph plugin. This output includes a TCP header and a Ceph header portion that has a pointer to the memory location where the Ceph read data is stored.

[0395] The TCP header is passed by hub 258 to the TCP packet payload ring within the Onload network stack.

[0396] A Ceph header containing a pointer to Ceph data within the DDR is passed to the packet payload ring in the Onload network stack. In some embodiments, the contents of the Ceph header are opaque to the Onload network stack. The Onload network treats this Ceph data as "application" data. Please note that other applications may be supported, either alternatively or additionally.

[0397] The Ceph client reads a TCP socket, receives data stored in the packet payload ring, which is a Ceph header with a pointer from the packet payload ring, and completes the BDEV read call by providing a response to the BDEV interface. This results in output to the Virtio-blk758 (block proxy), which uses a data pointer to ensure the read response data is passed to a virtual machine on the host. The Virtio-blk triggers a DMA of the Ceph read response data to host memory. A pointer to DDR is used, and a DMA operation is performed to provide the read data to host memory. The Ceph client is unaware of the nature of the pointer. The Ceph client sees the pointer being passed via the BDEV interface. It is the Virtio-blk758SPDK plugin that can invoke a hardware DMA operation on the pointer.

[0398] The network stack's TCP state control uses the TCP header to determine whether a SACK (selective acknowledgement) or ACK should be sent back to the source of the Ceph read response. The TCP header contains a sequence number, which can be used to determine which packets were received and whether any packets are missing. The SACK / ACK indicates to the Ceph peer's TCP stack whether the TCP data needs to be retransmitted. Ceph (both the software part 754 and the plug-in or hardware part 768) ensures that a reliable byte stream, including retransmissions, is handled at the TCP layer.

[0399] The TCP SACK / ACK is injected into the first hub 252. The TCP SACK / ACK is passed to the VNIC TX engine 240. From the VNIC TX engine, the TCP SACK / ACK is passed to the MAE 244 via the second hub 254. The TCP SACK / ACK is passed to the third hub 256 and output to the network transmit port streaming engine 208 for output onto the network.

[0400] Please note that TCP SACK / ACK may be processed as it passes through the streaming subsystem to be in a format suitable for transmission over the network.

[0401] A TCP reinjection ring may be provided to control the reinjection of TCP packets. This may be to re-establish the order of the TCP packet flow. The TCP packet sequence number is used to determine whether one or more packets need to be reordered. The TCP reinjection ring may receive instructions from the first plugin via the Ceph plugin and hub 258 for one or more packets to be reinjected. The TCP reinjection ring may allow the Ceph plugin to resume hardware processing of application data following network retransmission or out-of-order data reception.

[0402] TCP packets that are to be reinjected have their TCP header removed from the TCP packet header ring and their Ceph header removed from the packet payload ring.

[0403] The reinjected TCP packets are served to the first hub 252, passed to the VNIC TX engine 240, and directed to the MAE 244 via the second hub 254. The reinjected packets are then passed to the first plug-in via hub 256.

[0404] Since all exception routing data is sent to the software, the reinjected packet contains all the payload data that the Ceph plugin processes as if it were received from the network. This is the only point where the data is stored in the local DDR. The first and second plugs process the reinjected packet so that the TCP header is passed to the packet header ring and a Ceph header containing the data pointer of the reinjected packet is added to the packet payload ring.

[0405] Alternatively, the Ceph plugin stores all exception routing data in the DDR, even for out-of-order data. In this embodiment, the reinjected packet may include a TCP header and a Ceph header containing a pointer to the DDR. The reinjected packet may not include data stored in the DDR. The reinjected packet may include an indication that the packet is a reinjected packet.

[0406] In another embodiment, the TCP stack (or other transport protocol processing stack) may be fully implemented in hardware. This stack may perform all protocol operations, including retransmission. In this embodiment, the Onload software may be omitted. The Ceph plug-in 792 may directly deliver a data pointer to the location of the data in the DDR 770 to the software-based Ceph client 754.

[0407] Therefore, in some embodiments, data plane hardware performs a reassembly operation and parses the header from the data. In some embodiments, this data plane hardware may be provided by one or more plug-ins to the streaming subsystem. In some embodiments, the data may be held in a local buffer of the hardware plug-in.

[0408] In some embodiments, headers may be delivered to the software via queue pairs. These headers include the control plane portion of the data within the capsule. The software may be used to perform control plane functions. The software may handle protocol processing. For example, the software may provide TCP protocol processing, which may include handling the retransmission process.

[0409] Some embodiments may provide storage virtualization.

[0410] In some embodiments, block storage read / write commands may be virtualized on the host such that only header information is processed by the embedded CPU.

[0411] In the illustrated embodiment, a plugin is used. Please note that different streaming subsystem structures can be used, including the Onload and Ceph hardware within the data flow without using plugins for the Onload and Ceph hardware.

[0412] In this embodiment, Ceph, Onload, and SPDK are used. These are just examples, and other embodiments may use any other suitable computer program.

[0413] In some embodiments, a network interface device is provided having an input configured to receive a storage response containing a plurality of data packets, each data packet containing a header portion and data to be stored. The header portion includes a transport protocol header and a data storage application header. The network interface device includes a first packet processor configured to receive a plurality of packets, perform transport protocol processing, and provide transport protocol processed packets. The network interface device includes a second packet processor configured to receive transport protocol processed packets from the first packet processor, write the data to be stored to memory, and provide an output containing a data storage application header and a pointer to the location in memory where the data to be stored has been written.

[0414] Refer to Figure 15 to see how this is performed by a network interface device.

[0415] In 1501, the method includes receiving a storage response which includes a header and a plurality of data packets, each containing the data to be stored, the header including a transport protocol header and a data storage application header.

[0416] In 1502, this method includes processing multiple received transport protocol-processed packets using the transport protocol.

[0417] In 1503, the method includes processing a transport protocol-processed packet to write the data to be stored into memory within a network interface device, and providing output that includes a data storage application header and a pointer to the location in memory where the data to be stored has been written.

[0418] While the aspects and features may sometimes be described in individual figures, it should be understood that features from one figure can be combined with features from another figure, even if the combination is not explicitly shown or described as such.

[0419] The description of the apparatus of the present invention provided herein is illustrative and not intended to be exhaustive or limit to the disclosed forms and examples. The terms used herein have been selected to describe the principle of the apparatus of the present invention, its practical application, or a technical improvement over the technology available on the market, and / or to enable those skilled in the art to understand the apparatus of the present invention disclosed herein. Modifications and variations may be apparent to those skilled in the art without departing from the scope and spirit of the described apparatus of the invention. Therefore, the following claims, rather than the foregoing disclosures, should be referenced to illustrate the scope of such features and implementations.

Claims

1. A network interface device, An input configured to receive a storage response containing multiple data packets, wherein each of the multiple data packets includes a header portion and data to be stored, and the header portion includes a transport protocol header and a data storage application header. A first packet processor configured to receive the plurality of packets, perform transport protocol processing, and provide the transport protocol processed packets, A second packet processor is configured to receive the transport protocol processed packets from the first packet processor, write the data to be stored into memory, and provide output including the data storage application header and a pointer to the location in memory where the data to be stored has been written. The network interface device is configured to support at least a portion of a transport protocol processing application, and the second packet processor is configured to provide the transport protocol header, the data storage application header, and the pointer to the transport protocol processing application.

2. The network interface device according to claim 1, wherein the network interface device is configured to provide at least a portion of a data storage application.

3. The network interface device according to claim 2, wherein the data storage application includes at least one of a Ceph application, a Non-Volatile Memory Express (NVMe) application, or a distributed object store application.

4. The network interface device according to claim 2, wherein the operating system configured to run the data storage application is a different operating system from the operating system of the block storage application that makes the corresponding storage request.

5. The network interface device according to claim 2, wherein the data storage application is configured to (a) access a network via a user-space network stack, (b) access local storage associated with the data storage application via a user-space storage stack, or (c) store the data using direct memory access via a user-space storage stack.

6. The network interface device according to claim 1, further comprising a virtualized storage backend function, wherein the virtualized storage backend function is configured to receive storage requests from a host.

7. The network interface device according to claim 1, wherein the storage response includes a read response to a data storage application, and the read response is provided in response to a read request from the data storage application.

8. The network interface device according to claim 1, wherein the first packet processor is configured to determine whether one or more of the plurality of packets are out of order, and when it is determined that one or more of the plurality of packets are out of order, the first packet processor is configured to provide the out of order packets to the second packet processor along with the associated instructions.

9. The network interface device according to claim 8, wherein the second packet processor is configured to send the stored data of the out-of-order packets to a transport protocol processing application without storing the data in memory.

10. The network interface device according to claim 8, wherein the second packet processor is configured to send the data storage application header of the out-of-order packets, the transport protocol header of the out-of-order packets, and the stored data of the out-of-order packets to a transport protocol processing application without storing the data in memory, and does not provide a pointer to a location in memory.

11. The network interface device according to claim 10, further comprising the transport protocol processing application, the transport protocol processing application configured to cause the out-of-order packets to be provided to the input such that the out-of-order packets are injected in sequential positions within the plurality of packets and injected packets are generated.

12. The network interface device according to claim 11, wherein the first packet processor is configured to process the injected packets and provide output to the second packet processor, and the second packet processor is configured to write the stored data of the injected packets to memory.

13. The network interface device according to claim 8, wherein the second packet processor is configured to write the data of the out-of-order packets to memory, the network interface device comprises a transport protocol processing application, the transport protocol processing application is configured to inject packets based on the out-of-order packets into the plurality of packets received by the input, in order relative to the plurality of packets, and the injected packets comprise the transport protocol header, the data storage application header, and the pointer to a location in memory where the data to be stored is written.

14. The network interface device according to claim 1, further comprising a transport protocol processing application, wherein the transport protocol processing application is configured to determine whether the plurality of packets are in order, and when it is determined that the plurality of packets are not in order, the transport protocol processing application is configured to cause the out-of-order packets to be injected into the input at the correct positions relative to the other packets among the plurality of packets.

Images