From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F41B9A0535; Tue, 4 Feb 2020 20:52:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1570C1C21B; Tue, 4 Feb 2020 20:52:25 +0100 (CET) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by dpdk.org (Postfix) with ESMTP id 685FB1C21A for ; Tue, 4 Feb 2020 20:52:23 +0100 (CET) Received: by mail-il1-f176.google.com with SMTP id v13so16976740iln.4 for ; Tue, 04 Feb 2020 11:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SbdRJ+O9W4KWMDrlo379Ynq/9CmoxyS5KVcisJTWm7A=; b=sj9zPLDb2niC6unC7bQrwYAFP0cjzwMsWp5y24kQ52vxnIfxjTYkceMCEKH7W/cWCE xb8BLkWvjAPTdEH71FXFGrvEbP3VyUxpxKJGqtEK3NOUWoZYAIFyYXbpK4QISIUEHaAa 01HjhZy8WC3ULeOO4JiPB9jsXl+xHseN3KEPjfK4gzB9m1t/CqGZcMZtlvhjr9+9+TVJ EpZg3KfHGAicvA2cvhv5Lg2MeKfqh6i2YhXRvRkRS1CdJhXSZHS9AaK9zcjWD/qa9/pj s0tHfOUTPeeez8D1kTw/yUqy3+IMU6mzBLW77xHk4UqRtWvjho9Uy1ru2i59kIPXCwQg DwIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SbdRJ+O9W4KWMDrlo379Ynq/9CmoxyS5KVcisJTWm7A=; b=SOc2K5algs09lC4nOnUBVeVz9ySh41NqFpYn+5vokwo/c+dKXNrxAxGfAnz+lO1kRP Op0C75tEjwsn4XoggtuXrLn40KAb53i9K1DUhv2HnYzGF+rzZveHMaYyMNHVOofZPsm1 KzcV2x/GYUKRawr4Z272kiNFVsrWLZPHz9uqPPqUE/fl3h2nV/au18kj6JKzzVHlDIAW h4qqNi93g6IA0x/ZUXCJmin1MqzWG/e+kb9PcnKxBor5xuQnG94JwreZbtIZwE6TPNbc Wb1pXsS0SNEOOXDgayZwfneJk6mkmOeGuAha/u/nApj1L0NGxWm2a5LMZyOSD+WFR0u5 JP6g== X-Gm-Message-State: APjAAAW4ltc+mFlpKI3O8qKDlVhrTJoZBoSgAoU9Uwvzyj7t2og3I8ba pTumjL9HKnYjNiW3nZKAM4sACSejQvshzwH02as= X-Google-Smtp-Source: APXvYqwfZUXf1e0/4kZTEhpkMOP2xkbAEF8CqjW1MV5MTG65KIBZO3KqdPJqIkzzWbS1kawt9YMxj4ypcVZWfmLbkuI= X-Received: by 2002:a92:c747:: with SMTP id y7mr27155541ilp.60.1580845942643; Tue, 04 Feb 2020 11:52:22 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> In-Reply-To: <1580827512-178449-1-git-send-email-david.coyle@intel.com> From: Jerin Jacob Date: Wed, 5 Feb 2020 01:22:05 +0530 Message-ID: To: David Coyle Cc: dpdk-dev , "Doherty, Declan" , Fiona Trahe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote: > > Introduction > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 operatio= n, thereby allowing these to be performed in parallel in optimized software= libraries or in a hardware accelerator. These functions can include crypto= graphy, compression and CRC/checksum calculation, while others can potentia= lly be added in the future. Performing these functions in parallel as a sin= gle operation can enable a significant performance improvement. > > > Background > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > There are a number of byte-wise operations which are present and common a= cross many access network data-plane pipelines, such as Cipher, Authenticat= ion, CRC, Bit-Interleaved-Parity (BIP), other checksums etc. Some prototypi= ng has been done at Intel in relation to the 01.org access-network-dataplan= es project to prove that a significant performance improvement is possible = when such byte-wise operations are combined into a single pass of packet da= ta 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 cryp= todev 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > The primary use cases for this new library have already been mentioned. T= hese are: > > - DOCSIS MAC: Crypto-CRC > - Order: > - Downstream: CRC, Encrypt > - Upstream: Decrypt, CRC > - Specifications: > - Crypto: 128-bit AES-CFB encryption variant for DOCSIS a= s described in section 11.1 of DOCSIS 3.1 Security Specification (https://a= pps.cablelabs.com/specification/CM-SP-SECv3.1) > - CRC: Ethernet 32-bit CRC as defined in Ethernet/[ISO/IE= C 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/IE= C 8802-3] > - BIP: 4-byte bit-interleaved even parity (BIP) field com= puted over the entire FS frame, refer to ITU-T G.989.3, sections 8.1.1.5 a= nd 8.1.2.3 (https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.9= 89.3-201510-I!!PDF-E) >