From: Jerin Jacob <jerinjacobk@gmail.com>
To: David Coyle <david.coyle@intel.com>
Cc: dpdk-dev <dev@dpdk.org>,
"Doherty, Declan" <declan.doherty@intel.com>,
Fiona Trahe <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions
Date: Wed, 5 Feb 2020 01:22:05 +0530 [thread overview]
Message-ID: <CALBAE1Mh8qqWq-SWzBhVuWcSUzKFQiZT=u-PBCn2mFFMnQBuKg@mail.gmail.com> (raw)
In-Reply-To: <1580827512-178449-1-git-send-email-david.coyle@intel.com>
On Tue, Feb 4, 2020 at 8:15 PM David Coyle <david.coyle@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)
>
next prev parent reply other threads:[~2020-02-04 19:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 14:45 David Coyle
2020-02-04 19:52 ` Jerin Jacob [this message]
2020-02-06 10:04 ` Coyle, David
2020-02-06 10:54 ` Jerin Jacob
2020-02-06 16:31 ` Coyle, David
2020-02-06 17:13 ` Jerin Jacob
2020-02-07 12:38 ` Coyle, David
2020-02-07 14:18 ` Jerin Jacob
2020-02-07 20:34 ` Stephen Hemminger
2020-02-08 7:22 ` Jerin Jacob
2020-03-05 17:01 ` Coyle, David
2020-03-06 8:43 ` Jerin Jacob
2020-02-13 11:50 ` Doherty, Declan
2020-02-18 5:15 ` Jerin Jacob
2020-02-13 11:44 ` Doherty, Declan
2020-02-18 5:30 ` Jerin Jacob
2020-02-13 11:31 ` Doherty, Declan
2020-02-18 5:12 ` Jerin Jacob
2020-03-05 16:44 Coyle, David
2020-03-06 9:06 ` Jerin Jacob
2020-03-06 14:55 ` Coyle, David
2020-03-06 16:22 ` Jerin Jacob
2020-03-13 18:00 ` Coyle, David
2020-03-13 18:03 ` Jerin Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1Mh8qqWq-SWzBhVuWcSUzKFQiZT=u-PBCn2mFFMnQBuKg@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=david.coyle@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).