On Tue, Feb 4, 2020 at 8:15 PM David Coyle <david.co...@intel.com> wrote: > > Introduction > ============ > > This RFC introduces a new DPDK library, rte_accelerator. > > The main aim of this library is to provide a flexible and extensible way of > combining one or more packet-processing functions into a single operation, > thereby allowing these to be performed in parallel in optimized software > libraries or in a hardware accelerator. These functions can include > cryptography, compression and CRC/checksum calculation, while others can > potentially be added in the future. Performing these functions in parallel as > a single operation can enable a significant performance improvement. > > > Background > ========== > > There are a number of byte-wise operations which are present and common > across many access network data-plane pipelines, such as Cipher, > Authentication, CRC, Bit-Interleaved-Parity (BIP), other checksums etc. Some > prototyping has been done at Intel in relation to the 01.org > access-network-dataplanes project to prove that a significant performance > improvement is possible when such byte-wise operations are combined into a > single pass of packet data processing. This performance boost has been > prototyped for both XGS-PON MAC data-plane and DOCSIS MAC data-plane > pipelines.
Could you share the relative performance numbers to show the gain? > > The prototypes used some protocol-specific modifications to the DPDK > cryptodev library. In order to make this performance improvement consumable > by network access equipment vendors, a more extensible and correct solution > is required that can be upstreamed into DPDK. > > Hence, the introduction of rte_accelerator. > > > Use Cases > ========= > > The primary use cases for this new library have already been mentioned. These > are: > > - DOCSIS MAC: Crypto-CRC > - Order: > - Downstream: CRC, Encrypt > - Upstream: Decrypt, CRC > - Specifications: > - Crypto: 128-bit AES-CFB encryption variant for DOCSIS as > described in section 11.1 of DOCSIS 3.1 Security Specification > (https://apps.cablelabs.com/specification/CM-SP-SECv3.1) > - CRC: Ethernet 32-bit CRC as defined in Ethernet/[ISO/IEC > 8802-3] > > - XGS-PON MAC: Crypto-CRC-BIP > - Order: > - Downstream: CRC, Encrypt, BIP I understand if the chain has two operations then it may possible to have handcrafted SW code to do both operations in one pass. I understand the spec is agnostic on a number of passes it does require to enable the xfrom but To understand the SW/HW capability, In the above case, "CRC, Encrypt, BIP", It is done in one pass in SW or three passes in SW or one pass using HW? > - Upstream: BIP, Decrypt, CRC > - Specifications: > - Crypto: AES-128 [NIST FIPS-197] cipher, used in counter > mode (AES-CTR), as described in [NIST SP800-38A]. > - CRC: Ethernet 32-bit CRC as defined in Ethernet/[ISO/IEC > 8802-3] > - BIP: 4-byte bit-interleaved even parity (BIP) field > computed over the entire FS frame, refer to ITU-T G.989.3, sections 8.1.1.5 > and 8.1.2.3 > (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.989.3-201510-I!!PDF-E) >
