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 C0853A0573; Thu, 5 Mar 2020 17:44:07 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 101272BE3; Thu, 5 Mar 2020 17:44:07 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 18E502BB8 for ; Thu, 5 Mar 2020 17:44:04 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 08:44:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,518,1574150400"; d="scan'208";a="439560157" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga005.fm.intel.com with ESMTP; 05 Mar 2020 08:44:03 -0800 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 08:44:03 -0800 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by ORSMSX156.amr.corp.intel.com (10.22.240.22) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 08:44:03 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.175) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 08:44:03 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QYAYX16GcY3fUX92sYR5xmVPrqpDoO03S2miBh0s5hHrwqM5PDckXOG5L+uwOHA31Zee09QSEntVTnq81Oc9f0MHdFs13JgP32xPVRwqDFEUIs32FzhbLgWGbIGekIzh1nX+0h1Kf5cVh/GAmb+xV336KAM25SGfgz/W73bS2N23NeICrL7ls9rGESBG1IGq3M/wedfJkJHKeB4K27hXwwKWMBCYo7yOpaoZlrPzWpDGs27i/1EgQq6OTXM6aHkYyfzxhk6FVzPvNbwjT4EmikMt04RN1SUmSl998ejHh2l0tARgtZk7zFWIscW4/yB5q5v2qwPZxk5mHLrxa4bm9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OygosrmWTY8kC2ogQkuM9gTs0vI67jOQyHJQTvoUBVo=; b=RVjnR+GBJZ3KDsKcI9KFt/qAYcf3TmgcjGow4y5PQ1DxTYccJjssgaCdITvgt0XZSCWKulBaEKRPwW0vggXM71z/P8uIPyzlhEU9NQPtbmm1JBu9Eauuy9CwWGWo1h4IiM7UJEBRqneTYTljIGytBOPvKs3295RYQV/JZ149e83NzpHvDAjtU17nFikjeNH40PdB0weMQawyEyxE66mef/plDA9WzbG+jbgzDf6lBGtdcfhZeSkQduXCS5P+2sGlrv95TO8gaUI7RiCXXIjI+akn3f/3qLyqxhatEF7SgJD4bqEVYX6DUnPNd7xbil5Vt/J1gHI/6YfX6lOWtF82ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OygosrmWTY8kC2ogQkuM9gTs0vI67jOQyHJQTvoUBVo=; b=lG0mLtn2arADAoM8Ns40uThxmHF+K4ofu5CzRlFNg7tb2XLrvktIo5sNcyCfIuW8He02nynbOwFENtMl3MqCn2aujZ1y+NIlVrmdMNFLykvj1K81bycqAqo3QOlY1yzjtBUfrs1gSznvDaZQJ/E4wwLGq+NtGVFVm9g4TADT790= Received: from SN6PR11MB3086.namprd11.prod.outlook.com (2603:10b6:805:d6::14) by SN6PR11MB2942.namprd11.prod.outlook.com (2603:10b6:805:cb::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 5 Mar 2020 16:44:00 +0000 Received: from SN6PR11MB3086.namprd11.prod.outlook.com ([fe80::349a:eac4:f7ec:e806]) by SN6PR11MB3086.namprd11.prod.outlook.com ([fe80::349a:eac4:f7ec:e806%5]) with mapi id 15.20.2772.019; Thu, 5 Mar 2020 16:44:00 +0000 From: "Coyle, David" To: "dev@dpdk.org" , Jerin Jacob , "stephen@networkplumber.org" CC: "Doherty, Declan" , "Trahe, Fiona" Thread-Topic: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions Thread-Index: AdXzBy70QgRpjYGBQkWXr8yUzWXqFg== Date: Thu, 5 Mar 2020 16:44:00 +0000 Message-ID: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.coyle@intel.com; x-originating-ip: [192.198.151.165] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70771170-69d3-4b6e-39e3-08d7c124683b x-ms-traffictypediagnostic: SN6PR11MB2942: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(136003)(376002)(396003)(189003)(199004)(478600001)(316002)(54906003)(30864003)(110136005)(6506007)(66446008)(66476007)(66556008)(64756008)(8676002)(86362001)(8936002)(26005)(81156014)(186003)(66946007)(2906002)(4326008)(81166006)(55016002)(7696005)(107886003)(33656002)(9686003)(5660300002)(52536014)(76116006)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2942; H:SN6PR11MB3086.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P3J2rbK8iXKceZBWcFxPh568UHglg7/CAMoBNiFjMNP8J7mlJBNFWjZofQvh2rg4R0fRz0qBKG2noGPO+rjEeSw8Y5g4/v4D43kyR6bbwRA6sLUly/WH7wv1b8oNo8i0u6NQVXJJynLCp404pYRt5dSc2NQ4ESaz+tqJArr8Q+1m65+G9vALQImiSJRVfLQHclsx5c7MsswXAjq2rBPo0ny73qtJmrQR/I6HxOXFxJq/m3kY/9u/Zp+ax+eWyUvuhz0S96NG8N07qKOGqMYUeDmKaQK6FvqeUC2xmy3LmEoxaZuYFmPi6jHSTqMil1kciH3ZG4fnMlYG8ivlS5pVQlGusRpwOxVIwgcn7ANs1+FsUih1UHvc6BztOtZi1+HmlG5R2s0WndGse3Mq4cCXvOwt2jT6xkqWe7lw0+5tF6JMSMMDv2O3eNNLDIxiKD+P x-ms-exchange-antispam-messagedata: ZsRljyztvUq0vdsmCNtUtv7RQ5IvAQ6oxcbMkTFaOoA3OGD6B5R/Klqoc/3SsjIyWwaEgt8/mbQqgv3Ss0OJzdDEGQUR8FsPjI5czVAF18Bge/CgC2uW6EbPr7sUTbTNSAq+vwH7LupbKKGcnY4c8Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 70771170-69d3-4b6e-39e3-08d7c124683b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 16:44:00.6470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 58Wxwd+72aUbhSKFdj+lZUv3XFwLpzClgK5YXKFtZI/VRXZmsulOJtjetILXntFFPuXx1bmYDKOWZJTm99gHUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2942 X-OriginatorOrg: intel.com 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" Having taken feedback from the community into account, we would like to pro= pose some changes to our approach for combining multiple packet-processing = functions into a single operation on a single device, be that an optimized = software library or a hardware accelerator. The main feedback on the rte_accelerator API can be summarized as follows: 1) Why are we creating another new library that performs tasks similar to o= ther existing APIs... why not try and converge on one? 2) The term "accelerator" is too broad a term, if the API is primarily focu= sed on Crypto + CRC We also felt that using the rte_cryptodev and rte_compressdev APIs to initi= alize, configure and reset the devices and then using rte_accelerator for s= ession creation and operation enqueue/dequeue was confusing matters. We believe the new approach addresses the above concerns and also greatly s= implifies the solution. Our new approach proposes to use the already existing rte_rawdev API with s= ome added functionality for creating "multi-function" sessions. At the high level, the main changes are: - The rte_accelerator library will no longer be added - The rte_rawdev API will be used to initialize, configure, reset a device - A new rawdev interface for "multi-function" sessions/operations will be = added under the new directory 'drivers/raw/common' - this interface's header file will be called 'rte_rawdev_multi_fn.h' (wi= th an accompanying C file for function implementations) - this header file will contain much of what was previously included in r= te_accelerator.h and rte_err_detect.h, such as: - enums and structs for defining a multi-function chain of xforms, using= xform definitions from rte_cryptodev and rte_compressdev as necessary - enums and structs for defining a multi-function chain of ops, again us= ing op definitions from rte_cryptodev and rte_compressdev as necessary - enums and structs for defining error-detection xforms and ops - two API function definitions to create and destroy a session based on = a xform chain - rte_rawdev_multi_fn_session_create() - rte_rawdev_multi_fn_session_destroy() - application code will include rte_rawdev_multi_fn.h to access the struc= ts, enums and functions for creating xform chains, sessions and op chains - keeping the multi-function interface under the 'drivers' directory mean= s that rte_rawdev itself remains completely "raw", with no knowledge of xfo= rms, sessions or ops - a proposal for this header file is included at the end - The rte_rawdev API will be used to enqueue/dequeue the operations using = the existing rte_rawdev_enqueue_buffers() and rte_rawdev_dequeue_buffers() - a synchronous API function could potentially be added to rte_rawdev in = the future if required, to avoid the overhead of enqueue/dequeue for the op= timized software library use-case (e.g. rte_rawdev_process_buffers()) - Two new rawdev PMDs for will be added under 'drivers/raw' for QAT and AE= SNI-MB - these two rawdev PMDs will use and implement the multi-function interfa= ce defined in 'drivers/raw/common/rte_rawdev_multi_fn.h' - as with all other rawdev PMDs, the interface is known only to the appli= cation and the PMD itself, and is opaque to rte_rawdev itself - the PMDs will be added under 'drivers/raw/aesni_mb' and 'drivers/raw/qa= t' - other PMDs (existing or new) could use this multi-function interface in= the future if use-cases arise - The rte_rawdev library will be used as is, with no changes required =09 The initial use cases for the multi-function rawdev interface remain the sa= me as for the previously proposed rte_accelerator: - DOCSIS MAC: Crypto + CRC - XGS-PON MAC: Crypto + CRC + BIP However, the API can still also accommodate other chained functions such as= Compression + Crypto and UDP Checksum + Crypto. The following diagram shows the new architecture: +-----------------------------------------------------------+ | | | Application | | (e.g. vCMTS (DOCSIS), vOLT (XGS-PON), etc.) | | | +-----------------------------------------------------------+ | +---------------------------|-------------------------------+ | | DPDK | | | | | +---------------------+ | | | | | | | rte_rawdev | | | | | | = NOTE: | +---------------------+ ____________|_______ 'R= AWDEV MULTI-FUNCTION | / \ / | = API' is opaque to | / \ / | = rte_rawdev | / \ / | | +--------------------------------+ | | | RAWDEV MULTI-FUNCTION API | | | +--------------------------------+ | | +------------+ +------------+ | | | RAWDEV | | RAWDEV | | | | AESNI-MB | | QAT | | | | PMD | | PMD | | | +------------+ +------------+ | | | | | +------------------|------------------|---------------------+ | | +------------+ +------------+ | AESNI-MB | | QAT HW | | SW LIB | | | +------------+ +------------+ Note that development work is already progressing well on this new approach= , with the aim of upstreaming this into DPDK v20.05. Also, we may consider consolidating the multi-function API into the main DP= DK library in the future if there were more devices which wanted to support= these multi-function operations. The following is the proposed rawdev multi-function interface, defined in '= drivers/raw/common/rte_rawdev_multi_fn.h' /* SPDX-License-Identifier: BSD-3-Clause * Copyright(c) 2020 Intel Corporation. */ #ifndef _RTE_RAWDEV_MULTI_FN_H_ #define _RTE_RAWDEV_MULTI_FN_H_ #ifdef __cplusplus extern "C" { #endif #include #include #include #include #include #include #include #include /** Error Detection Algorithms */ enum rte_rawdev_multi_fn_err_detect_algorithm { RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH, /**< CRC32 Ethernet */ RTE_RAWDEV_MULTI_FN_ERR_DETECT_BIP32 /**< BIP32 */ }; /** Error Detection Operation Types */ enum rte_rawdev_multi_fn_err_detect_operation { RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_VERIFY, /**< Verify error detection result */ RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_GENERATE /**< Generate error detection result */ }; /** Error Detection Status */ enum rte_rawdev_multi_fn_err_detect_op_status { RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_STATUS_NOT_PROCESSED, /**< Operation has not yet been processed by a device */ RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_STATUS_SUCCESS, /**< Operation completed successfully */ RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_STATUS_VERIFY_FAILED, /**< Verification failed */ RTE_RAWDEV_MULTI_FN_ERR_DETECT_OP_STATUS_ERROR /**< Error handling operation */ }; /** * Error Detection Transform Data * * This structure contains data relating to an error detection transform. T= he * fields *op* and *algo* are common to all error detection transforms and * MUST be set */ struct rte_rawdev_multi_fn_err_detect_xform { enum rte_rawdev_multi_fn_err_detect_operation op; /**< Error detection operation type */ enum rte_rawdev_multi_fn_err_detect_algorithm algo; /**< Error detection algorithm */ }; /** Error Detection Operation */ struct rte_rawdev_multi_fn_err_detect_op { struct rte_mbuf *m_src; /**< Source mbuf */ enum rte_rawdev_multi_fn_err_detect_op_status status; /**< Operation status */ struct { uint16_t offset; /**< * Starting point for error detection processing, specified * as the number of bytes from start of the packet in the * source mbuf */ uint16_t length; /**< * The length, in bytes, of the source mbuf on which the error * detection operation will be computed */ } data; /**< Data offset and length for error detection */ struct { uint8_t *data; /**< * This points to the location where the error detection * result should be written (in the case of generation) or * where the purported result exists (in the case of * verification) * * The caller must ensure the required length of physically * contiguous memory is available at this address * * For a CRC, this may point into the mbuf packet data. For * an operation such as a BIP, this may point to a memory * location after the op * * For generation, the result will overwrite any data at this * location */ rte_iova_t phys_addr; /**< Physical address of output data */ } output; /**< Output location */ }; /** * Multi-function transform types */ enum rte_rawdev_multi_fn_xform_type { RTE_RAWDEV_MULTI_FN_XFORM_TYPE_CRYPTO_SYM, /**< Symmetric crypto transform type */ RTE_RAWDEV_MULTI_FN_XFORM_TYPE_CRYPTO_ASYM, /**< Asymmetric crypto transform type */ RTE_RAWDEV_MULTI_FN_XFORM_TYPE_COMP, /**< Compression transform type */ RTE_RAWDEV_MULTI_FN_XFORM_TYPE_ERR_DETECT /**< Error detection transform type */ }; /** * Multi-function transform setup data * * This structure is used to specify the multi-function transforms required= . * Multiple transforms can be chained together to specify a chain of transf= orms * such as symmetric crypto followed by error detection, or compression fol= lowed * by symmetric crypto. Each transform structure holds a single transform, = with * the type field specifying which transform is contained within the union. */ struct rte_rawdev_multi_fn_xform { struct rte_rawdev_multi_fn_xform *next; /**< * Next transform in the chain * - the last transform in the chain MUST set this to NULL */ enum rte_rawdev_multi_fn_xform_type type; /**< Transform type */ RTE_STD_C11 union { struct rte_crypto_sym_xform crypto_sym; /**< Symmetric crypto transform */ struct rte_crypto_asym_xform crypto_asym; /**< Asymmetric crypto transform */ struct rte_comp_xform comp; /**< Compression transform */ struct rte_rawdev_multi_fn_err_detect_xform err_detect; /**< Error detection transform */ }; }; /** * Multi-function operation status */ enum rte_rawdev_multi_fn_op_status { RTE_RAWDEV_MULTI_FN_OP_STATUS_SUCCESS =3D 0, /**< Operation completed successfully */ RTE_RAWDEV_MULTI_FN_OP_STATUS_FAILURE, /**< Operation completed with failure */ RTE_RAWDEV_MULTI_FN_STATUS_INVALID_SESSION, /**< Operation failed due to invalid session arguments */ RTE_RAWDEV_MULTI_FN_OP_STATUS_NOT_PROCESSED, /**< Operation has not yet been processed by a device */ }; /** * Multi-function session data */ struct rte_rawdev_multi_fn_session; /** * Multi-function operation data * * This structure is used to specify the operations for a particular sessio= n. * This includes specifying the source and, if required, destination mbufs = and * the lengths and offsets of the data within these mbufs on which the * operations should be done. Multiple operations are chained together to * specify the full set of operations to be performed * * @note The rte_rawdev_multi_fn_op chain MUST match the session's xform * chain exactly * @note The first rte_rawdev_multi_fn_op element in the chain is the paren= t * operation. The following fields MUST be set in this first operation befo= re * enqueuing and are ignored in the inner operations and any subsequent * rte_rawdev_multi_fn_op chain elements: * - *sess* * - *m_src* * - *m_dst* (if required) * @note If *sess* or *m_src* is not set in the first rte_rawdev_multi_fn_o= p, * this operation is invalid and will cause an error when attempting to enq= ueue. * @note The following fields MUST be set in ALL rte_rawdev_multi_fn_op cha= in * elements: * - *next* * - *mempool* * - *type* * @note After the operation has been dequeued, only the FIRST (i.e. the pa= rent) * rte_rawdev_multi_fn_op in the chain will contain the *overall_status*. E= ach * chain element will contain it's individual *op_status*, the value of whi= ch is * relevant to operation type (e.g. an ::rte_crypto_op_status, * ::rte_comp_op_status or ::rte_err_detect_op_status) */ struct rte_rawdev_multi_fn_op { struct rte_rawdev_multi_fn_op *next; /**< * Next operation in the chain * - the last operation in the chain MUST set this to NULL */ struct rte_rawdev_multi_fn_session *sess; /**< Handle for the associated multi-function session */ struct rte_mempool *mempool; /**< Mempool from which the operation is allocated */ struct rte_mbuf *m_src; /**< Source mbuf */ struct rte_mbuf *m_dst; /**< Destination mbuf */ enum rte_rawdev_multi_fn overall_status; /**< * Overall operation status * - indicates if all the operations in the chain succeeded or if any * one of them failed */ uint8_t op_status; /**< * Individual operation status * - indicates the status of the individual operation in the chain */ RTE_STD_C11 union { struct rte_crypto_sym_op crypto_sym; /**< Symmetric crypto operation */ struct rte_crypto_asym_op crypto_asym; /**< Asymmetric crypto operation */ struct rte_comp_op comp; /**< Compression operation */ struct rte_rawdev_multi_fn_err_detect_op err_detect; /**< Error detection operation */ }; }; /** * Create multi-function session as specified by the transform chain * * @param dev_info Device info, obtained by calling rte_rawdev_info_get() * @param xform Pointer to the first element of the session transform * chain * @param socket_id Socket to allocate the session on * * @return * - Pointer to session, if successful * - NULL, on failure */ __rte_experimental struct rte_rawdev_multi_fn_session * rte_rawdev_multi_fn_session_create(struct rte_rawdev_info *dev_info, struct rte_rawdev_multi_fn_xform *xform, int socket_id); /** * Free memory assoicated with a multi-function session * * @param dev_info Device info, obtained by calling rte_rawdev_info_get() * @param sess Multi-function session to be freed * * @return * - 0, if successful * - -EINVAL, if session is NULL * - -EBUSY, if not all session data has been freed */ __rte_experimental int rte_rawdev_multi_fn_session_destroy(struct rte_rawdev_info *dev_info, struct rte_rawdev_multi_fn_session *sess); #ifdef __cplusplus } #endif #endif /* _RTE_RAWDEV_MULTI_FN_H_ */