Patent ID: 12248416

DETAILED DESCRIPTION OF EMBODIMENTS

Overview

Embodiments of the present invention that are described herein provide improved methods and systems for user-defined implementation (e.g., software emulation) of peripheral devices in computing systems. In the disclosed embodiments, a network adapter provides users with means for specifying user-defined peripheral devices. This framework is referred to herein as user defined peripheral-bus device implementation (UDDI).

Peripheral devices that can be specified and implemented using the disclosed techniques include, for example, network adapters (e.g., Network Interface Controllers—NICs), storage devices (e.g., Solid State Drives—SSDs), Graphics Processing Units (GPUs) and Field-Programmable Gate Arrays (FPGAs). UDDI may be performed over various types of peripheral buses, e.g., Peripheral Component Interconnect express (PCIe), Compute Express Link (CXL) bus, NVLink and NVLink-C2C. In the present context, the terms “emulation” of a device and “user-defined implementation” of a device are used interchangeably.

As will be described below, the disclosed network adapter comprises a hardware-implemented data-path that comprises various packet-processing engines used for network communication. In addition, the network adapter comprises a programmable Data-Plane Accelerator (DPA) that runs user-programmable logic implementing the UDPD. The DPA implements (e.g., emulates) the UDPD by reusing one or more of the packet-processing engines of the network adapter's data-path.

Various examples of using the same packet-processing engines for network communication and for UDDI are described herein. Data-path packet-processing engines that can be reused for network communication and for UDDI comprise, for example, transport engines, address translation engines, Direct Memory Access (DMA) engines, message-signaled-interrupt (MSI/MSI-X) engines, interrupt moderation engines, doorbell aggregation engines, as well as various “memory-to-memory” accelerators that perform computations such as compression/decompression, encryption/decryption and hashing.

In some embodiments the network adapter communicates over the peripheral bus with a host or other external device. The network adapter exposes two bus interfaces over the peripheral bus, one interface used for network communication and the other interface (referred to as “UDPD interface” or “UDDI interface”) used for UDDI. The host runs two software drivers-A “native NIC driver” (also referred to as “network-adapter driver”) for performing network communication, and a UDPD driver for interacting with the UDPD. Both drivers are accessible to user applications running on the host.

The methods and systems described herein enable users a high degree of flexibility in specifying peripheral devices. By carrying out the UDDI tasks in the network adapter, the disclosed techniques offload the host of such tasks, and also provide enhanced security and data segregation between different users. By reusing data-path packet-processing engines for both network communication and UDDI, implementation in the network adapter is simpler and more efficient in terms of cost, size and power consumption (“performance per Watt”).

System Description

FIG.1is a block diagram that schematically illustrates a computing system20employing user defined peripheral-bus device implementation (UDDI), in accordance with an embodiment of the present invention. System20comprises a network adapter, in the present example a Network Interface Controller (NIC)24, which serves a host28. Host28and NIC24communicate with one another over a peripheral bus, in the present example a PCIe bus34. NIC24is connected to a network32, e.g., an Ethernet of InfiniBand™ network.

Host28comprises a host CPU36(also referred to as a host processor) and a host memory40, e.g., a Random-Access Memory (RAM). Host processor36runs various user applications (not seen in the figure). The user applications may communicate over network32using NIC24, and/or interact with one or more User-Defined Peripheral Devices (UDPD) implemented on NIC24. Host processor36runs a native NIC driver44for providing network-communication services to the user applications, and a UDPD driver48for providing UDDI services to the user applications.

The configuration of system20seen inFIG.1is an example, non-limiting configuration. For example, alternatively to PCIe, the peripheral bus may comprise a CXL bus, an NVLink bus, an NVLink-C2C bus, or any other suitable peripheral bus. Host28is regarded herein as an example of an external device that can be served by NIC24. Additionally or alternatively, an external device may comprise, for example, a peer device (e.g., GPU or FPGA) coupled to bus34or to the host. A host may be part of a multi-host configuration, in which NIC24serves multiple hosts over separate respective logical buses.

In some embodiments, NIC24comprises one or more network ports52for communicating over network32, and a host interface56(also referred to as a bus interface) for communicating with host28(or other external device) over bus34. NIC24further comprises a hardware-implemented data path60and a programmable Data-Plane Accelerator (DPA)64. Data path60comprises a plurality of hardware-implemented packet-processing engines that perform various processing tasks needed for network communication between host28and network32, e.g., for sending and receiving packets. DPA64runs, possibly among other tasks, user-programmable logic that implements the UDPD. As will be explained below, DPA60implements the UDPD by reusing one or more of the packet-processing engines of data path60.

In the embodiment ofFIG.1, data path60comprises the following packet-processing engines:A transport engine68—An engine responsible for packet transport reliability and transport protocol implementation.An address translation engine72. Given a host virtual address (VA) and a memory key (MKEY) that identifies the buffer registration, address translation engine72translates the host virtual address into an IO Virtual Address (IOVA). Engine72may support one or more translation types, such as, for example:Direct mapping-A mapping that translates VAs into respective IOVAs, within the address space defined by the MKEY.Indirect mapping-A mapping that translates VAs into one or more additional IOVAs or {MKEY, VA} pairs, wherein MKEY may be either direct or indirect (the final step of indirection being a direct-mapped MKEY).Patterned mapping (“strided mapping”)—A mapping that translates VAs into respective one or more IOVAs or {MKEY, VA} pairs in accordance with a periodic pattern of addresses. Each MKEY may be either direct or indirect.One or more DMA engines76. A given engine76is able to perform parallel, asynchronous and variable-size DMA operations (e.g., DMA read and DMA write) in host memory40. DMA engine76typically receives an instruction comprising an opcode (read/write), one or more IOVAs (or one or more {MKEY, VA} pairs that are then translated into IOVAs) and a length, and executes the requested PCIe transactions to carry out the instruction. In case of a write instruction, the request descriptor may also comprise the data to be written (“inline data”).(In some embodiments, DPA64or data path60may additionally comprise one or more asynchronous DMA engines that are used only for UDDI.) An asynchronous DMA engine typically receives instructions from DPA64to move data between host memory40and the DPA memory (fetch data from the host memory to the DPA memory, or write data from the DPA memory to the host memory), executes the instructions asynchronously without blocking forward process of the DPA, and reports to the DPA once execution is completed.An MSI-X engine84. An engine that issues MSIX-type interrupts to host processor36, and/or interrupts to DPA64.An interrupt moderation engine88—An engine that throttles the rate of interrupts issued toward host processor36and/or toward DPA64. Interrupt moderation engine88can be configured with a maximum rate of interrupts and/or with a maximum latency permitted in coalescing interrupts.A doorbell aggregation engine80—An engine that coalesces multiple doorbells, issued by host processor36, to a single queue. This sort of coalescing enables NIC24to execute only the last doorbell without pre-emption from other doorbells. Since in some embodiments UDDI queues are cyclic, doorbell aggregation engine80can store only the last producer index of the queue.One or more memory-to-memory accelerators92—Accelerators that accelerate complex computations. A given accelerator92typically reads its operands from memory and writes its output back to memory. Computations that may be accelerated include, for example, compression, decompression, encryption, decryption and hash-function evaluation.

The configurations of system20and its various components, e.g., NIC24and host28, as depicted inFIG.1, are example configurations that are chosen purely for the sake of conceptual clarity. Any other suitable configurations can be used in alternative embodiments.

In various embodiments, the disclosed techniques can be used for implementing any suitable peripheral device, e.g., network adapters, storage devices that support various storage protocols, GPUs, FPGAs, etc. User-defined (e.g., emulated) storage devices may support various storage protocols, e.g., Non-Volatile Memory express (NVMe), block-device protocols such as virtio-blk, local or networked file systems, object storage protocols, network storage protocols, etc. Further aspects of UDDI and device emulation are addressed, for example, in U.S. patent application Ser. No. 17/211,928, entitled “Storage Protocol Emulation in a Peripheral Device,” filed Mar. 25, 2021, in U.S. patent application Ser. No. 17/372,466, entitled “Network Adapter with Efficient Storage-Protocol Emulation,” filed Jul. 11, 2021, in U.S. patent application Ser. No. 17/527,197, entitled “Enhanced Storage Protocol Emulation in a Peripheral Device,” filed Nov. 16, 2021, and in India Patent Application 202241052839, entitled “User-Defined Peripheral-Bus Device Implementation,” filed Sep. 15, 2022, which are assigned to the assignee of the present patent application and whose disclosures are incorporated herein by reference.

It is noted that the term “user” may refer to various entities, whether individuals or organizations. For example, in a given system, a user-defined peripheral device may be specified by one “user” but accessed by (interfaced with) by a different “user”. For example, the user specifying the user-defined peripheral device may be an infrastructure owner, whereas the user using the user-defined peripheral device may be a consumer. In a cloud environment, for example, the former user would be a Cloud Service Provider (CSP) and the latter user could be a guest or tenant. In some cases, however, a user-defined peripheral device may be specified and used by the same user.

In various embodiments, the various components of NIC24and host28can be implemented using hardware, e.g., using one or more Application-Specific Integrated Circuits (ASIC) and/or Field-Programmable Gate Arrays (FPGA), using software, or using a combination of hardware and software components.

In some embodiments, at least some of the functions of the disclosed system components, e.g., some or all functions of host CPU36and/or DPA64, are implemented using one or more general-purpose processors, which are programmed in software to carry out the functions described herein. The software may be downloaded to the processors in electronic form, over a network, for example, or it may, alternatively or additionally, be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory.

UDDI with Reuse of Data-Path Engines by DPA

When implementing a UDPD, the UDPD interface exposed by NIC24typically appears to a user application as a dedicated, local peripheral device. The actual peripheral device, however, may be located remotely from host28(e.g., across network32), shared by one or more other user applications and/or designed to use a different native interface than the user application, or emulated entirely using software.

Thus, in general, user-defined implementation of a peripheral device may involve accessing local devices, communication over a network with remote devices, as well as protocol translation. These operations typically involve sending and/or receiving data units to and from network32, as well as processing data units in NIC24.

Depending on the kind of peripheral device being implemented and the protocols involved, data units that are processed by NIC24may comprise, for example, packets, messages, data blocks, data objects, descriptors, contexts, work requests, completions, or any other suitable kind of data units. Some types of data units may be communicated over network32, other types may be communicated with the host, and yet other types may be processed only internally in the NIC.

The embodiments described herein refer mainly to packets, for the sake of clarity, but the disclosed techniques are applicable to data units of any other suitable type. For clarity, data units (e.g., packets) that are processed by NIC24as part of UDDI, i.e., as part of implementing a user-defined peripheral device, are referred to as UDPD data units (with UDPD packets being an example). By the same token, data units (e.g., packets) that are processed by NIC24as part of network communication are referred to as communication data units (with communication packets being an example).

Using the above terminology, when serving user applications that run on host28, NIC24reuses one or more of the processing engines of data path60for both (i) processing of communication packets as part of network communication using native NIC driver44, and (ii) processing of UDPD packets as part of UDDI using UDPD driver48.

Typically, although not necessarily, when processing communication packets, data path60operates in a pipelined manner, with one processing engine triggering another processing engine. This operation is typically independent of DPA64. When processing UDPD packets, on the other hand, the various processing engines are typically invoked by DPA64as needed.

Reuse of Data-Path Engines-Inbound Packets

FIG.2is a flow chart that schematically illustrates a method for processing inbound communication packets and User-Defined Peripheral Device (UDPD) packets in NIC24, in accordance with an embodiment of the present invention.

The left-hand side of the figure shows the processing of communication packets (also referred to as “communication process”). This process typically does not involve DPA64. The right-hand side of the figure shows the processing of UDPD packets (also referred to as “UDDI process”). Operations that reuse the same packet-processing engine are marked in the figure by a connecting dashed line.

The communication process (left-hand side of the flow chart) begins with NIC24receiving a communication packet from network32via one of ports52, at a communication packet reception stage100.

At a transport processing stage104, transport engine68performs applicable checks and offloads on the communication packet. Checks may comprise, for example, verification of the IP checksum and TCP checksum and/or checking of the network address (e.g., check for MAC spoofing or for invalid addresses). Offloads may comprise, for example, header decapsulation in tunneled protocols, management of Large Receive Offload (LRO) sessions, and termination of reliability protocols in RDMA such as Packet Sequence Number (PSN) checks. If all checks pass successfully, transport engine68selects a Receive Queue (RQ) for the packet, and issues a translation request to address translation engine72for the next buffer in the RQ.

At an address translation stage108, address translation engine72translates the RQ buffer address into one or more IOVAs. At a packet scattering stage112, DMA engine76scatters the packet to the IOVA. In some embodiments, the packet may be processed by one or more of memory-to-memory accelerators92as needed, e.g., to decompress and/or decrypt the packet.

At a completion scattering stage116, DMA engine76scatters a completion of the packet to a Completion Queue (CQ) in host28.

In some cases (e.g., depending on user configuration) the completion may trigger MSIX engine84to generate an MSIX to host processor36, at an interrupt generation stage120. When configured, interrupt moderation engine88may throttle the rate of MSIX issued toward the host, at an interrupt moderation stage124.

The UDDI process (right-hand side of the flow chart) begins with NIC24receiving a UDPD packet from network32via ports52, at a UDPD packet reception stage130.

At a transport processing stage134, transport engine68performs the applicable checks on the UDPD packet, e.g., verifies the IP checksum and TCP checksum, and the network address. If the checks pass successfully, the transport engine68selects a Receive Queue (RQ) for the packet. In this case, however, the RQ is associated with DPA64. In some embodiments the DPA receives the packet on its selected RQ. In other embodiments the packet is written directly to host memory40, and only packet arrival is issued to the DPA.

At a UDDI stage138, DPA64performs the applicable user-defined logic on the UDPD packet. As part of this stage, DPA64may invoke one or more of memory-to-memory accelerators92as needed, e.g., to decompress and/or decrypt the packet.

At a translation requesting stage142, the DPA issues a translation request to address translation engine72for the target buffer. At an address translation stage146, address translation engine72translates the RQ buffer address into one or more IOVAs.

At a packet scattering stage150, DMA engine76scatters the UDPD packet to the one or more IOVAs. At a completion requesting stage154, DPA64sends a command to DMA engine76to scatter a completion. In response, in some embodiments, DMA engine76scatters a completion of the packet to a Completion Queue (CQ) in host28, at a completion scattering stage158. In other embodiments, a different scheme for completion indication (e.g., incrementing of a counter) can be used.

In some cases (e.g., depending on user configuration) the completion may trigger MSIX engine84to generate an MSIX to host processor36, at an interrupt generation stage162. When configured, interrupt moderation engine88may throttle the rate of MSIX issued toward the host, at an interrupt moderation stage166.

Reuse of Data-Path Engines—Outbound Packets

FIG.3is a flow chart that schematically illustrates a method for processing outbound communication packets and UDPD packets in NIC24, in accordance with an embodiment of the present invention. Here, too, the left-hand side of the flow chart shows the processing of communication packets (referred to as “communication process”), and the right-hand side of the flow chart shows the processing of UDPD packets (referred to as “UDDI process”). Operations that reuse the same packet-processing engine are marked in the figure by a connecting dashed line.

The communication process (left-hand side of the flow chart) begins with NIC24receiving a doorbell from native NIC driver44, indicating a new outbound communication packet to be processed. The doorbell typically specifies a Send Queue (SQ) address. Doorbell aggregation engine80receives and processes the doorbell, at a doorbell processing stage170.

Address translation engine72translates the SQ buffer address (and/or one or more other addresses contained in the request which exist in the SQ buffer, e.g., a Work Queue Element (WQE) containing a pointer to data) into IOVA, at a translation stage174. At a fetching stage178, DMA engine76fetches the descriptors and payload of the communication packet from host memory40, thereby composing the communication packet. In some embodiments, the packet may be processed by one or more of memory-to-memory accelerators92as needed, e.g., to compress and/or encrypt the packet.

At a transport processing stage182, transport engine68processes the packet, including, for example, calculating and/or verifying fields such as IP checksum, TCP checksum and network addresses, and/or performing offloads such as Large Send Offload (LSO). Transport engine68may implement the transport layer, fully or partially, such as add RDMA Packet Sequence Numbers (PSNs), etc. At a transmission stage186, the communication packet is transmitted to network32via one of ports52.

At a completion scattering stage190, DMA engine76scatters a completion of the packet to the host CQ. In some cases (e.g., depending on user configuration), the completion may trigger MSIX engine84to generate an MSIX to host processor36, at an interrupt generation stage194. When configured, interrupt moderation engine88may throttle the rate of MSIX issued toward the host, at an interrupt moderation stage198.

The UDPD process (right-hand side of the flow chart) begins with NIC24receiving a doorbell from UDPD driver48, indicating a new outbound UDPD packet to be processed. The doorbell typically specifies a UDDI queue address. In some embodiments, doorbell aggregation engine80receives and processes the doorbell, at a doorbell processing stage202. At a doorbell trapping stage206, DPA64traps the doorbell and executes the applicable user-defined processing to the trapped doorbell.

At a fetch requesting stage210, DPA64issues a command to DMA engine76to fetch the descriptors and data of the UDPD packet from host memory40. At an address translation stage214, address translation engine72translates the SQ buffer address (and/or additional addresses indicated by the descriptors in the SQ buffer, such as virtio-net available-ring that points to a descriptor table, which in turn points to packets and/or additional entries in the descriptor table) into IOVA. At a fetching stage218, DMA engine76fetches the descriptors and payload of the UDPD packet from host memory40, thereby composing the UDPD packet.

At a UDDI stage222, DPA64performs the applicable user-defined logic on the UDPD packet. As part of this stage, DPA64may invoke one or more of memory-to-memory accelerators92as needed, e.g., to compress and/or encrypt the packet.

At a send requesting stage226, in some embodiments the DPA issues a command to transport engine68to send the packet. At a transport processing stage230, transport engine68processes the packet, including, for example, calculating and/or verifying fields such as IP checksum, TCP checksum and network addresses. At a transmission stage234, the communication packet is transmitted to network32via one of ports52.

At a completion requesting stage238, DPA64sends a command to DMA engine76to scatter a completion. In response, DMA engine76scatters a completion of the packet to a Completion Queue (CQ) in host28, at a completion scattering stage242. As noted above, a CQ is only one possible way of indicating completion. In other embodiments, any other implementation can be used, e.g., using a counter.

In some cases (e.g., depending on user configuration) the completion may trigger MSIX engine84to generate an MSIX to host processor36, at an interrupt generation stage246. When configured, interrupt moderation engine88may throttle the rate of MSIX issued toward the host, at an interrupt moderation stage250.

Although the embodiments described herein mainly address user-defined implementation of peripheral-bus devices, the methods and systems described herein can also be used in other applications, such as in implementing sub-device functionality within an existing device.

It will thus be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. Documents incorporated by reference in the present patent application are to be considered an integral part of the application except that to the extent any terms are defined in these incorporated documents in a manner that conflicts with the definitions made explicitly or implicitly in the present specification, only the definitions in the present specification should be considered.