Abstract: Examples described herein relate to a host interface and circuitry. In some examples, the circuitry, when coupled to a physical device, is to: perform operations of a hypervisor. In some examples, the host interface is configured to route first communications to the circuitry instead of the physical device and route second communications to the physical device. In some examples, the physical device is accessible as a virtual device via the host interface.

Abstract: Examples described herein relate to a network interface device that includes a programmable event processing architecture comprising a plurality of programmable event processors. When the plurality of programmable event processors are operational, one or more of the programmable event processors are to perform memory accesses separate from compute operations, group one or more events into at least one group, enforce atomic processing of other events within a group of the at least one group, wherein the atomic processing comprises propagation of state changes to among events of the group, and perform parallel processing of events belonging to different groups.

Abstract: Examples described herein relate to a network interface device that includes a programmable event processing architecture that includes a plurality of programmable event processors. In some examples, the plurality of programmable event processors are to perform memory accesses separate from compute operations. In some examples, the plurality of programmable event processors are to group one or more events into at least one group. In some examples, the plurality of programmable event processors are to perform parallel processing of events belonging to different groups. In some examples, the plurality of programmable event processors are programmed to perform at least one transport protocol.

Abstract: Examples described herein relate to a network interface device that includes circuitry to receive storage access command and determine a processing path in the network interface device for the storage access command, wherein the processing path is within the network interface device and wherein the processing path is selected from direct mapped or control plane processed based at least on command type and source of command. In some examples, the command type is read or write.

Abstract: Examples described herein relate to a network interface device that includes circuitry to perform operations, offloaded from a host, to identify at least one locator of at least one target storage associated with a storage access command based on operations selected from among multiple available operations, wherein the available operations comprise two or more: entry lookup by the network interface device, hash-based calculation on the network interface device, or control plane processing on the network interface device.

Abstract: Technologies for flexible I/O protocol acceleration include a computing device having a root complex, a smart endpoint coupled to the root complex, and an offload complex coupled to the smart endpoint. The smart endpoint receives an I/O transaction that originates from the root complex and parses the I/O transaction based on an I/O protocol and identifies an I/O command. The smart endpoint may parse the I/O transaction based on endpoint firmware that may be programmed by the computing device. The smart endpoint accelerates the I/O command and provides a smart context to the offload complex. The smart endpoint may copy the I/O command to memory of the smart endpoint or the offload complex. The smart endpoint may identify protocol data based on the I/O command and copy the protocol data to the memory of the smart endpoint or the offload complex. Other embodiments are described and claimed.

Abstract: Technologies for flexible I/O endpoint acceleration include a computing device having a root complex, a soft endpoint coupled to the root complex, and an offload complex coupled to the soft endpoint. The soft endpoint establishes an emulated endpoint hierarchy based on endpoint firmware. The computing device may program the endpoint firmware. The soft endpoint receives an I/O transaction that originates from the root complex and determines whether to process the I/O transaction. The soft endpoint may process the I/O transaction or forward the I/O transaction to the offload complex. The soft endpoint may encapsulate the I/O transaction with metadata and forward the encapsulated transaction to the offload complex. The soft endpoint may store responses from the offload complex in a history buffer and retrieve the responses in response to retried I/O transactions. The I/O transaction may be a PCI Express transaction layer packet. Other embodiments are described and claimed.

Abstract: Technologies for flexible I/O endpoint acceleration include a computing device having a root complex, a soft endpoint coupled to the root complex, and an offload complex coupled to the soft endpoint. The soft endpoint establishes an emulated endpoint hierarchy based on endpoint firmware. The computing device may program the endpoint firmware. The soft endpoint receives an I/O transaction that originates from the root complex and determines whether to process the I/O transaction. The soft endpoint may process the I/O transaction or forward the I/O transaction to the offload complex. The soft endpoint may encapsulate the I/O transaction with metadata and forward the encapsulated transaction to the offload complex. The soft endpoint may store responses from the offload complex in a history buffer and retrieve the responses in response to retried I/O transactions. The I/O transaction may be a PCI Express transaction layer packet. Other embodiments are described and claimed.

Abstract: An addressless merge command includes an identifier of an item of data, and a reference value, but no address. A first part of the item is stored in a first place. A second part is stored in a second place. To move the first part so that the first and second parts are merged, the command is sent across a bus to a device. The device translates the identifier into a first address ADR1, and uses ADR1 to read the first part. Stored in or with the first part is a second address ADR2 indicating where the second part is stored. The device extracts ADR2, and uses ADR1 and ADR2 to issue bus commands. Each bus command causes a piece of the first part to be moved. When the entire first part has been moved, the device returns the reference value to indicate that the merge command has been completed.

Abstract: Packet information is stored in split fashion such that a first part is stored in a first device and a second part is stored in a second device. A split packet transmission DMA engine receives an egress packet descriptor. The descriptor does not indicate where the second part is stored but contains information about the first part. Using this information, the DMA engine causes a part of the first part to be transferred from the first device to the DMA engine. Address information in the first part indicates where the second part is stored. The DMA engine uses the address information to cause the second part to be transferred from the second device to the DMA engine. When both the part of the first part and the second part are stored in the DMA engine, then the entire packet is transferred in ordered fashion to an egress device.

Abstract: A chained Command/Push/Pull (CPP) bus command is output by a first device and is sent from a CPP bus master interface across a set of command conductors of a CPP bus to a second device. The chained CPP command includes a reference value. The second device decodes the command, in response determines a plurality of CPP commands, and outputs the plurality of CPP commands onto the CPP bus. The second device detects when the plurality of CPP commands have been completed, and in response returns the reference value back to the CPP bus master interface of the first device via a set of data conductors of the CPP bus. The reference value indicates to the first device that an overall operation of the chained CPP command has been completed.

Abstract: A method for supporting in-flight packet processing is provided. Packet processing devices (microengines) can send a request for packet processing to a packet engine before a packet comes in. The request offers a twofold benefit. First, the microengines add themselves to a work queue to request for processing. Once the packet becomes available, the header portion is automatically provided to the corresponding microengine for packet processing. Only one bus transaction is involved in order for the microengines to start packet processing. Second, the microengines can process packets before the entire packet is written into the memory. This is especially useful for large sized packets because the packets do not have to be written into the memory completely when processed by the microengines.

Abstract: In response to receiving a novel “Return Available PPI Credits” command from a credit-aware device, a packet engine sends a “Credit To Be Returned” (CTBR) value it maintains for that device back to the credit-aware device, and zeroes out its stored CTBR value. The credit-aware device adds the credits returned to a “Credits Available” value it maintains. The credit-aware device uses the “Credits Available” value to determine whether it can issue a PPI allocation request. The “Return Available PPI Credits” command does not result in any PPI allocation or de-allocation. In another novel aspect, the credit-aware device is permitted to issue one PPI allocation request to the packet engine when its recorded “Credits Available” value is zero or negative. If the PPI allocation request cannot be granted, then it is buffered in the packet engine, and is resubmitted within the packet engine, until the packet engine makes the PPI allocation.

Abstract: Within a networking device, packet portions from multiple PDRSDs (Packet Data Receiving and Splitting Devices) are loaded into a single memory, so that the packet portions can later be processed by a processing device. Rather than the PDRSDs managing and handling the storing of packet portions into the memory, a packet engine is provided. The PDRSDs use a PPI (Packet Portion Identifier) Addressing Mode (PAM) in communicating with the packet engine and in instructing the packet engine to store packet portions. The packet engine uses linear memory addressing to write the packet portions into the memory, and to read the packet portions from the memory.

Abstract: In response to receiving a “Return Available PPI Credits” command from a credit-aware (CA) device, a packet engine sends a “Credit To Be Returned” (CTBR) value it maintains for that device back to the CA device, and zeroes out its stored CTBR value. The CA device adds the credits returned to a “Credits Available” value it maintains. The CA device uses the “Credits Available” value to determine whether it can issue a PPI allocation request. The “Return Available PPI Credits” command does not result in any PPI allocation or de-allocation. In another aspect, the CA device issues one PPI allocation request to the packet engine when its recorded “Credits Available” value is zero or negative. If the PPI allocation request cannot be granted, then it is buffered in the packet engine, and is resubmitted within the packet engine, until the packet engine makes the PPI allocation.

Abstract: Within a networking device, packet portions from multiple PDRSDs (Packet Data Receiving and Splitting Devices) are loaded into a single memory, so that the packet portions can later be processed by a processing device. Rather than the PDRSDs managing and handling the storing of packet portions into the memory, a packet engine is provided. The PDRSDs use a PPI (Packet Portion Identifier) Addressing Mode (PAM) in communicating with the packet engine and in instructing the packet engine to store packet portions. A PDRSD requests a PPI from the packet engine in a PPI allocation request, and is allocated a PPI by the packet engine in a PPI allocation response, and then tags the packet portion to be written with the PPI and sends the packet portion and the PPI to the packet engine.

Abstract: Within a networking device, packet portions from multiple PDRSDs (Packet Data Receiving and Splitting Devices) are loaded into a single memory, so that the packet portions can later be processed by a processing device. Rather than the PDRSDs managing the storing of packet portions into the memory, a packet engine is provided. The PDRSDs use a PPI addressing mode in communicating with the packet engine and in instructing the packet engine to store packet portions. A PDRSD requests a PPI from the packet engine, and is allocated a PPI by the packet engine, and then tags the packet portion to be written with the PPI and sends the packet portion and the PPI to the packet engine. Once the packet portion has been processed, a PPI de-allocation command causes the packet engine to de-allocate the PPI so that the PPI is available for allocating in association with another packet portion.

Abstract: Within a networking device, packet portions from multiple PDRSDs (Packet Data Receiving and Splitting Devices) are loaded into a single memory, so that the packet portions can later be processed by a processing device. Rather than the PDRSDs managing and handling the storing of packet portions into the memory, a packet engine is provided. A device interacting with the packet engine can use a PPI (Packet Portion Identifier) Addressing Mode (PAM) in communicating with the packet engine and in instructing the packet engine to store packet portions. Alternatively, the device can use a Linear Addressing Mode (LAM) to communicate with the packet engine. A PAM/LAM selection code field in a bus transaction value sent to the packet engine indicates whether PAM or LAM will be used.

Abstract: A method for supporting in-flight packet processing is provided. Packet processing devices (microengines) can send a request for packet processing to a packet engine before a packet comes in. The request offers a twofold benefit. First, the microengines add themselves to a work queue to request for processing. Once the packet becomes available, the header portion is automatically provided to the corresponding microengine for packet processing. Only one bus transaction is involved in order for the microengines to start packet processing. Second, the microengines can process packets before the entire packet is written into the memory. This is especially useful for large sized packets because the packets do not have to be written into the memory completely when processed by the microengines.

Abstract: A chained Command/Push/Pull (CPP) bus command is output by a first device and is sent from a CPP bus master interface across a set of command conductors of a CPP bus to a second device. The chained CPP command includes a reference value. The second device decodes the command, in response determines a plurality of CPP commands, and outputs the plurality of CPP commands onto the CPP bus. The second device detects when the plurality of CPP commands have been completed, and in response returns the reference value back to the CPP bus master interface of the first device via a set of data conductors of the CPP bus. The reference value indicates to the first device that an overall operation of the chained CPP command has been completed.