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 6E0A0A00C5; Mon, 6 Jul 2020 12:02:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 410511DA43; Mon, 6 Jul 2020 12:02:32 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 20E231DA23 for ; Mon, 6 Jul 2020 12:02:30 +0200 (CEST) IronPort-SDR: 2YVjaoNyl05lLedXu0zbjgVxBFmLYBip11qPGl3lva1KcqXPe8AeyeYB+6lqNqslGOxo4wYA1z Yl6SZje7uxCg== X-IronPort-AV: E=McAfee;i="6000,8403,9673"; a="146463965" X-IronPort-AV: E=Sophos;i="5.75,318,1589266800"; d="scan'208";a="146463965" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2020 03:02:30 -0700 IronPort-SDR: C9aylk1jbOrsXc+PQ5sEzJICoyeKprB+mZt9dGPSFLhtBhWvTo+MzwNQY5Gmj4IkF1XZunu4ry hlljojOjbKjQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,318,1589266800"; d="scan'208";a="266503679" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga007.fm.intel.com with ESMTP; 06 Jul 2020 03:02:30 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SgzLSQj9r3GQMkbwEHlCwD2heOEKFv6wWfZhBpNP933LQrEqABAKHTbumYumLPtYVacqHhyY9h/wW0keBJIqMB3f2rQOG7xYp97BjYDs067OdJvQsDO6ZBzDGqtt0J8u/J+DuB05pmP4RH4az3dcu1QafC838Kp8ffr0JFjhyZzi7E23nkrKxG/NshoMRMBobv2p/GTLYegNdflfX9lXLi4ZoixhjrmGXvVwplQeuQ9/P38hvQ7j4wXhQt+uhC4JFCmkAtMS7lUvEWxtpsq1JPckYnnkmcMTbu3THb2PuTsAgnIUn369+tAVxXVLSZ6AEBoU33yQcwAjfaaEasqzKg== 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=18UzK/oljMc6bNB707B3kbpymULYALeFWVD1sqffTF0=; b=eUE2I1BFbYCn7uV8k9vM24NQIpOg8xP2qVK/AzNL6Hcn9tUQ2+ACR+veFEK7ILeI7OEeOGbJzZgZFI9V0LsIXJdQ10s4au0uV7yzg8C5ch7whgHkXQL9h2MoC91s5ElyfWPjnpogkAnXdSse3RCXZhBiPfPTmj6rS9NCfaAna7CMgufS6r4YybcXURJxIkiU3VXTpbnVbRaQ3fovj1q1zdovHL2d2L3HUQXJ93ylxAXj13q1lo5FEH6WwOqorPVFckM1dKN9CjcID9+atzUxz+FkkX99us9CD0ExVVZVb0Ac++B3ZosshpOMVesm1m7kt5VlpPe/WPKS6GheHBSt4g== 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=18UzK/oljMc6bNB707B3kbpymULYALeFWVD1sqffTF0=; b=ecmYXO4CXlSUgX774yCfIzj8qUgHGYR0zkTqXAdOtDQ7XIJCdsunfkdCT6/qKq3m1Q1ywrzeuFekNbLRCRHl+HiTJozQS8hBraaWsOX3O/uQrffmg8va7b8STGvrNIMjRi1myRuqTL2Wl2yWYCstu9Ir90f0kKY0vXWR/4SjXNQ= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by BL0PR11MB3457.namprd11.prod.outlook.com (2603:10b6:208:64::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.27; Mon, 6 Jul 2020 10:02:28 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::dd8e:7a6b:53ca:2a8a]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::dd8e:7a6b:53ca:2a8a%4]) with mapi id 15.20.3153.029; Mon, 6 Jul 2020 10:02:27 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "dev@dpdk.org" , "anoobj@marvell.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , Nagadheeraj Rottela , Michael Shamis , Ankur Dwivedi , Jay Zhou , "De Lara Guarch, Pablo" CC: "Trahe, Fiona" , "Bronowski, PiotrX" , "Ananyev, Konstantin" , Thomas Monjalon Thread-Topic: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path APIs Thread-Index: AQHWUTh9W23hQCo6PkeV7n4G/Cv9Iqj3u/CAgAKPEPA= Date: Mon, 6 Jul 2020 10:02:27 +0000 Message-ID: References: <20200703110923.26452-1-roy.fan.zhang@intel.com> <20200703124942.29171-1-roy.fan.zhang@intel.com> <20200703124942.29171-2-roy.fan.zhang@intel.com> In-Reply-To: Accept-Language: zh-Hans-HK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGY1NWE5NGMtNTliYy00NjhlLWJmZTMtZmVjMDdmYTgzZmI3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUm52UlVlR1wvTjdveUkxVllxUlY5b2d6ZkphSldnNm1zSjFBM3pva0hnVEZ1aGc3elN2Zm9HRjQrSTJ5SHpqNXoifQ== x-ctpclassification: CTP_NT dlp-version: 11.2.0.6 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b99864e3-4f82-407b-f237-08d82193b09c x-ms-traffictypediagnostic: BL0PR11MB3457: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04569283F9 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7sGZ3BcCuFpmB/Vl/+VFK13COELG+jXZQT0CmD1dzssXFOsXRnp/gCPWuyZMivGXh2f2Z1DUc1yuG6/bw2arKtwevWwdifkp3QAV/aDuXwkIn7L5sCkNj3z3Z6ZrzaZygA8ulGZdzA5hNuDBziUfKX6+TovsoxMmo1p2rJZSwIlWqRyFeh878eeupf8LQ712W2H6pA/DqMCFsARzrKvw1g4f4KES4BfC6zS3CKb/3UuiwwjjCb2iy0TlMcpfF1R/tMg1BRJ8EALJPGQxQyoJJJnefiZBY8xjZ67KB+ThrBWAovFlawr6WoOKtz8jRuIWZ7M5Sz0dYmJ3KhMXiZRDOTzzgSBVnTJZDZ2LpPZf6gQAQbnlwNBPnVFqn5gI7gBt x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(5660300002)(71200400001)(8676002)(6636002)(7696005)(186003)(316002)(19627235002)(4326008)(66476007)(66556008)(64756008)(66446008)(110136005)(54906003)(86362001)(26005)(53546011)(6506007)(52536014)(76116006)(8936002)(2906002)(83380400001)(66946007)(55016002)(33656002)(7416002)(478600001)(9686003)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: uUNCke0d2q+oHwIpqpxv79CMuSa/OYNwhWDUySFV/dRrd2Aow4egwea2rSVAPW+XNe8ujaRp+pQoHjTbOaYWhUZxSaNQW2sMMgLD10nKgmNnekW9iJpiTiHa3xsZAdyYETZFVB7UMvRu4EVV0m4gip35c7iuO6C8CSj9wMelw4fNJuVMNh4tBCXZsyFNFfqICwbJ1PptWgD3TFMi2V7ADfwgOAIalwAWIfw677hsO4kJ0v5vwHRRqtfTOVUyRcSx+gRA5Msi5S576txzo6nTY8jfztRjF/jx05JwMB5V0xL9Hla5yUPeen9axceMy09rvebSvzebdSm7thT5ljSm8/JCQ3MCWNGiEPzkQ/MH04wgHoRYprEE+HFfeCkfsKa0KekqzVW4s28X5abufatQzRM66J81LUrpJOccjEPeDkHeLX1QRxtsIEIVoMABmKHd0nRgGloQFZlCeizbjmNYOFvScyTRmVjyw+6UUr2E+lUAAXV9E/0g3LWaXXbF09R0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b99864e3-4f82-407b-f237-08d82193b09c X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 10:02:27.8380 (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: iLcE1qfPUSyiJIwuHEih6rhbeXU6r1/2mLFNGEVg44r2OSPYuiYPYyJxpk0q+rDesuKZ1q3oDlA4YO4klqH8bA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3457 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path APIs 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" Hi Akhil, > -----Original Message----- > From: Akhil Goyal > Sent: Saturday, July 4, 2020 7:16 PM > To: Zhang, Roy Fan ; dev@dpdk.org; > anoobj@marvell.com; asomalap@amd.com; ruifeng.wang@arm.com; > Nagadheeraj Rottela ; Michael Shamis > ; Ankur Dwivedi ; Jay > Zhou ; De Lara Guarch, Pablo > > Cc: Trahe, Fiona ; Bronowski, PiotrX > ; Ananyev, Konstantin > ; Thomas Monjalon > > Subject: RE: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path > APIs >=20 > Hi Fan, >=20 > > + > > +/** > > + * Asynchronous operation job descriptor. > > + * Used by HW crypto devices direct API call that supports such activi= ty > > + **/ > > +struct rte_crypto_sym_job { > > + union { > > + /** > > + * When RTE_CRYPTO_HW_ENQ_FLAG_IS_SGL bit is set in > flags, > > sgl > > + * field is used as input data. Otherwise data_iova is > > + * used. > > + **/ > > + rte_iova_t data_iova; > > + struct rte_crypto_sgl *sgl; > > + }; > > + union { > > + /** > > + * Different than cryptodev ops, all ofs and len fields have > > + * the unit of bytes (including Snow3G/Kasumi/Zuc. > > + **/ > > + struct { > > + uint32_t cipher_ofs; > > + uint32_t cipher_len; > > + } cipher_only; > > + struct { > > + uint32_t auth_ofs; > > + uint32_t auth_len; > > + rte_iova_t digest_iova; > > + } auth_only; > > + struct { > > + uint32_t aead_ofs; > > + uint32_t aead_len; > > + rte_iova_t tag_iova; > > + uint8_t *aad; > > + rte_iova_t aad_iova; > > + } aead; > > + struct { > > + uint32_t cipher_ofs; > > + uint32_t cipher_len; > > + uint32_t auth_ofs; > > + uint32_t auth_len; > > + rte_iova_t digest_iova; > > + } chain; > > + }; > > + uint8_t *iv; > > + rte_iova_t iv_iova; > > +}; >=20 > NACK, > Why do you need this structure definitions again when you have similar on= es > (the ones used in CPU crypto) available for the same purpose. > In case of CPU crypto, there were 2 main requirements > - synchronous API instead of enq +deq > - raw buffers. >=20 As you may have seen the structure definition is hW centric with the IOVA addresses all over. Also as you will from the patch series the operati= on is=20 Per operation basis instead of operating in a burst. The external applicati= on may sooner know when a specific enqueue is failed.=20 > Now for this patchset, the requirement is > - raw buffers > - asynchronous APIs >=20 > The data structure for raw buffers and crypto related offsets are already > defined > So they should be reused. > And I believe with some changes in rte_crypto_op and rte_crypto_sym_op, > We can support raw buffers with the same APIs. > Instead of m_src and m_dst, raw buffer data structures can be combined in= a > Union and some of the fields in the rte_crypto_op can be left NULL in cas= e of > raw buffers. >=20 This is a good point but we still face too many unnecessary fields to be NU= LL, such as digest pointers, I have given a lot thought to this structure. Hopefully it= covers all vendor's HW symmetric crypto needs and in the same time it well squeeze= =20 the required HW addresses into 1 cacheline, instead of rte_crypto_op +=20 rte_crypto_sym_op 3 cacheline footprint. Another purpose of the structure d= esign is the structure buffer can be taken from stack and can be used to fill all jobs to the PMD HW. >=20 > > +/* Struct for user to perform HW specific enqueue/dequeue function cal= ls > */ > > +struct rte_crypto_hw_ops { > > + /* Driver written queue pair data pointer, should NOT be alterred by > > + * the user. > > + */ > > + void *qp; > > + /* Function handler to enqueue AEAD job */ > > + rte_crypto_hw_enq_cb_fn enqueue_aead; > > + /* Function handler to enqueue cipher only job */ > > + rte_crypto_hw_enq_cb_fn enqueue_cipher; > > + /* Function handler to enqueue auth only job */ > > + rte_crypto_hw_enq_cb_fn enqueue_auth; > > + /* Function handler to enqueue cipher + hash chaining job */ > > + rte_crypto_hw_enq_cb_fn enqueue_chain; > > + /* Function handler to query processed jobs */ > > + rte_crypto_hw_query_processed query_processed; > > + /* Function handler to dequeue one job and return opaque data > stored > > */ > > + rte_crypto_hw_deq_one_cb_fn dequeue_one; > > + /* Function handler to dequeue many jobs */ > > + rte_crypto_hw_deq_many_cb_fn dequeue_many; > > + /* Reserved */ > > + void *reserved[8]; > > +}; >=20 > Why do we need such callbacks in the library? > These should be inside the drivers, or else we do the same for > Legacy case as well. The pain of finding the correct enq function for > Appropriate crypto operation is already handled by all the drivers > And we can reuse that or else we modify it there as well. >=20 Providing different types of enqueue functions for specific operation type could save a lot of branches for the driver to handle. As mentioned this data-path API is intended to be used as an advanced feature to provide close-to-native perf to external library/applications that are not mbuf centric. And I don't agree classifying choosing 1 enqueue function from 4 candidates as "pain". > We should not add a lot of data paths for the user, otherwise the > APIs will become centric to a particular vendor and it will be very diffi= cult > For the user to migrate from one vendor to another and would defeat the > Purpose of DPDK which provide uniform abstraction layer for all the > hardware > Vendors. >=20 The purpose of adding data-path for the user is performance for non-mbuf data-path centric applications/libraries, in the meantime not creating confusion. In this version we aim to provide a more friendly data-path for them, and aims to be useful to all vendor's PMDs. If there is any place in the API that blocks a PMD please let me know. > Adding other vendors to comment. >=20 > Regards, > Akhil