Abstract: The embodiments herein describe a communication protocol (which can be implemented in hardware or software) that provides efficient recover packet loss and can transit large messages in a complex network environment. In one embodiment, each data packet contains an encoded universal sequence which is unique across the sends, which enables cross-sender loss recovery. A receiver can include a transmission control module that controls the receiving buffer and maintains the buffer status and the sender's status. The transmission control module stores incoming packets to the correct position in the receiving buffer and generates acknowledgement notifications. The transmission control module also handles packet loss and out-of-order receiving of the packets containing the transactions.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Abstract: Examples herein describe a programmable traffic management engine that includes both programmable and non-programmable hardware components. The non-programmable hardware components are used to generate features that can then be used to perform different traffic management algorithms. Depending on which traffic management algorithm the PTM engine is configured to do, the PTM engine may use a subset (or all) of the features to perform the algorithm. The programmable hardware components in the PTM engine are programmable (e.g., customizable) by the user to perform a selected algorithm using some or all of the features provided by the non-programmable hardware components.

Abstract: Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. To avoid the latency that comes with using software, the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e., added) to a ledger of a permissioned blockchain.

Abstract: Examples herein describe an acceleration framework that includes a hybrid congestion control (CC) engine where some components are implemented in software (e.g., a CC algorithm) while other components are implemented in hardware (e.g., measurement and enforcement modules and a flexible processing unit). The hardware components can be designed to provide measurements that can be used by multiple different types of CC algorithms. Depending on which CC algorithms are currently enabled, the hardware components can be programmed to perform measurement, processing, and enforcement tasks, thereby freeing the CPUs in the host to perform other tasks. In this manner, the hybrid CC engine can have the flexibility of a pure software CC algorithm with the advantage of performing many of the operations associated with the CC algorithm in hardware.

Abstract: Embodiments herein describe a describe an interface shell in a SmartNIC that reduces data-copy overhead in CPU-centric solutions that rely on hardware compute engine (which can include one or more accelerators). The interface shell offloads tag matching and address translation without CPU involvement. Moreover, the interface shell enables the compute engine to read messages directly from the network without extra data copy—i.e., without first copying the data into the CPU's memory.

Abstract: Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. To avoid the latency that comes with using software, the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e., added) to a ledger of a permissioned blockchain.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Abstract: Examples herein describe a programmable traffic management engine that includes both programmable and non-programmable hardware components. The non-programmable hardware components are used to generate features that can then be used to perform different traffic management algorithms. Depending on which traffic management algorithm the PTM engine is configured to do, the PTM engine may use a subset (or all) of the features to perform the algorithm. The programmable hardware components in the PTM engine are programmable (e.g., customizable) by the user to perform a selected algorithm using some or all of the features provided by the non-programmable hardware components.