From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2CDDDA0C3F; Thu, 15 Apr 2021 12:15:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 082FD1621B2; Thu, 15 Apr 2021 12:15:03 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id D683A1621AD for ; Thu, 15 Apr 2021 12:15:01 +0200 (CEST) IronPort-SDR: AEzUwP7fVjA5fpoHL1QorxUSnBB7X2TvaMaJx3lLjLiB3hJRo9L/rlM/vZO4GyrDR9tzACK4MC jUOQ28AuJVIQ== X-IronPort-AV: E=McAfee;i="6200,9189,9954"; a="258787635" X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="258787635" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 03:14:59 -0700 IronPort-SDR: TM0V/ABbo6RLtTtlcRtaYUqwOi0/WJfg50vKjn5CzgYEx5zhT8UpF8pfFzAjahsxclAMR6+NCW 16pd9ut1v5oA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="382682376" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga003.jf.intel.com with ESMTP; 15 Apr 2021 03:14:59 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 15 Apr 2021 03:14:58 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Thu, 15 Apr 2021 03:14:58 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Thu, 15 Apr 2021 03:14:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SzG6xUgbNAu+sVzMt+Ze07UpdzjfOzo10DN3uNvBtHSK6tjGyVmav5bREhjSVhN0FPH/8sG/Qh5BPRZTEH/phtcEIJsyE6s/28AVQweMJ3Czqz2dT+jcGigbFRYcTAwd+ZBRViYWoYIh9AQtKUkfODORBgJq3nXoXE5q5cxzHKThgTB3ImWDljHhQR7QldcPQx8W7s61J6dL7gm04nvfDRmp6Kb3X46KhG6/djFBIWjBrzqsYn2Rdiaehx0cJOuVUzlw/o5PPa5YUCLsJiK2K648DvSUdf1TlZBRB72bKQ2MG3YAgSPDzENwAeDv6/tvABe2iRq+bCMS7OY3WIPpjg== 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=VQUeSLN/HjZ3wmlB/CUpjKIwU1E57oal/FyJf3vg8so=; b=H5xK0CfJKy7kcXOkdee45Vz8NvQtROUyGL+bEFBUvRFGQsza1yrcjEhp6KvMX+PR4dSEAuxAGCwtsUDmateshkd8Yv87kdcwph/h/R+O98Ax9/KUO0Tc7hetboD1i/OPiSANGbSMvZCojOsVx4k1VQanUXJ+dXf+uJxlOAhzdp+JXmL8pooJo8HyLWSxG6CN/WOG9puTi+Rg7R4DbFpwCGQmYq86dZ/sAhTquABWEWqtFECH2eFv89WwVTBvMyqNyenGCMJM1JzhcwpMHCvi5inlItzaOqoBBr9I6YfkVGv4XN3ZALgjcGdLgBpn5apLMM4T83HQQCcQmNQsWHeQUg== 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=VQUeSLN/HjZ3wmlB/CUpjKIwU1E57oal/FyJf3vg8so=; b=bghDL4LckUwuCiCLxmqmlaTNnyByeR+M7OQIGtUzFak3YLaPppiDkyoSn1/ZTd+0bvzwaVHuYakfbwvYAVtkgJMnngA315suh3KirDm4K5rn52OftQgbDuNeDFHDDBs/4uzCEfncqHptWWu9YfZ/m2h2E+PZhtZUDVghdXFUqx0= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4349.namprd11.prod.outlook.com (2603:10b6:208:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Thu, 15 Apr 2021 10:14:57 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::3174:e158:7eb8:7f2b]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::3174:e158:7eb8:7f2b%3]) with mapi id 15.20.4020.023; Thu, 15 Apr 2021 10:14:57 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "dev@dpdk.org" Thread-Topic: [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue API Thread-Index: AQHXJlIxlPyV1eczukSqXV1qqlrKmKqyUHAAgAMfzYA= Date: Thu, 15 Apr 2021 10:14:57 +0000 Message-ID: References: <20210316111455.509633-1-roy.fan.zhang@intel.com> <20210331172038.1718973-1-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: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [95.44.220.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ffc4904-4778-44fc-2003-08d8fff75241 x-ms-traffictypediagnostic: MN2PR11MB4349: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 00N0bR51ggX/j/Ulb5GSLG1GJkHe4N676HmN+0BnwFlIb8UH7lFOPEqLfyagcVxrCe77DZBbU71AOlUkGljh7oowk80U65MU3X9UfaNssZCDo0xiiEXWsMfNOzpomTzywXmKzP8V78RWC0db7lYW3lekLLhUGk18dug85JRb8/L7z9agCnCn+WOQm9pvDsehhgh4MFzcJVJ/HWw2B3zq86ssbFG9PL41Yj9Awzo76nQaRdXXrhivKiOw2EMbDWiG81rKthBUoPccNAOdZEogp/jEGCvbZhCYxDafAGBLaBMytRZ7fAwMNZY4GZUTJQg97huzBd0n+4GBMWB7lHMC+vLFBcOiFlkJn8mWp9+Hl/pURcEy2VDovq7uJ8MocfU1C7VGWYuBTVF/YU3UnGOIlaLSaz8KneJSRqBgYxHtjZ4ZgLilNrbdK+485qjgrBN+Qfh+CDfZd0eXtE48IS3BiInrqF1T7nTlovOwuJPw/bl+K5PgsuF3O5gl7npYbCajWlM6T8WOP6z3vVMY8GPfzMPgN7e09b2TXow5rfuPKTZDDq1MctyRroOtMSVWq5S2u0drThVwuDkWCHIIgTvazUkm4ItvL8iM8j3EI34FNyo= 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; SFS:(346002)(396003)(376002)(136003)(39860400002)(366004)(478600001)(8676002)(7696005)(5660300002)(6506007)(66556008)(316002)(26005)(9686003)(66446008)(53546011)(71200400001)(110136005)(64756008)(83380400001)(66476007)(33656002)(8936002)(52536014)(186003)(76116006)(66946007)(55016002)(122000001)(86362001)(2906002)(38100700002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?4PoQIspPvnJrFt4mOyK4FujhZ0PQK14iz1JOPaVanydnW0M770um0uHG?= =?Windows-1252?Q?WJNdThi0PTauy+qLkawVDZK9vxmEiN5QcsXtkPAO/cZ2j0H2Ip/KExDk?= =?Windows-1252?Q?HI0cJPwNLTLLdb2EjgrdaBu2YJOOn3a0hLFkDpgTvR7Sz/DE17wZmEbP?= =?Windows-1252?Q?zny5nJL6SSoW8+IpHEOi3bXyzXjhPS5MasnrZOfVob7BLneRCucYIz3w?= =?Windows-1252?Q?vjhoUlx7fc9zlVjuKY3Q0OTI5FKGny5G1p4Slok/YTtnJIc9hFNTMtbn?= =?Windows-1252?Q?J/NIF9b264F8ZVOf3Vlol+HzesRQ/W5dOxzKy5huVb/8vUfEeKXktlo2?= =?Windows-1252?Q?muqJZ1y6hhZ1o2tsZw6d+ZHtmFCKnesqehhpShOg2a6R+8m0Lpmvi0jl?= =?Windows-1252?Q?d94SuKq7swzOjIzZTysewPrYpnde0GHdAr94iB4vw1KjMLrDj5fg3hS2?= =?Windows-1252?Q?f/V6yDdTsjbnHRfuhJI9OlceUjL3PHyu1v1P7XdNPNlzfM7Q9pYwcCii?= =?Windows-1252?Q?PRczyuvg9ZWEkzOKFoMSwEEDjMAZGPYEjUU3t4T+5UGHJlKaGfrrCn84?= =?Windows-1252?Q?bG9e3qcs8Hf6sQwf3MLKXaAR74ErKkxST2l3qpdw78n0zW8+SS78bvS0?= =?Windows-1252?Q?401TwyeojpMejX0497VSgb3STm4X0+HlWWofBfNFM1d3/WVijBZOTKkX?= =?Windows-1252?Q?nril/EaWJE65WRWXjNcSL0B5gh69Hm8/++mMT2B2m1GQbz68nRnyFIyn?= =?Windows-1252?Q?FtN1K6rcotan9xtLlQU375EUjb9ynbl5FuySuqhU5krpbu5ToDgRWQ/v?= =?Windows-1252?Q?sksuB9n9832romUbSIK5jXxIkD22FLoBVKnoRPNG1djNGjeOUYl+igGz?= =?Windows-1252?Q?7zItV7i+BpM1JIyI1/5QwygCMu7gm3qcz4IB3GUIqPNWfUHTnNjAE2qj?= =?Windows-1252?Q?0E3wTlKjbyHfvslLBxgS5MtUquZkRUcN6YTLypHSMs0FeIsmwzUhAd61?= =?Windows-1252?Q?xf3XT+vui+iObRMGewjwprgeyQoT1uTRt443zbvSncF5evj+mwFmIyJO?= =?Windows-1252?Q?euU9gNaoYQQGUPtj+Q+icOf8f0K17HnsVSFTYoA91gj53ujAPdrKonnm?= =?Windows-1252?Q?3bHX+dYKKW1+y15srlc3JYfOw7pcmyUVnwHSM60T581U69Texxg+wjv1?= =?Windows-1252?Q?UvyKG7QsLW7EgkIXKyMz+pyR2NNCGx3x6B7TcEDe1JKmTD3av/f9UhBq?= =?Windows-1252?Q?MQzRm6dau3UEB+dGPH/KmlVnw9PtmOvHtlV20O4FtfKxtbR/m5BJ3IHz?= =?Windows-1252?Q?mkZcc8TxJr9NnsYiOfLCEN9jxseAWA0rkRCMWbNnwBIabngamosbltBe?= =?Windows-1252?Q?aRsflDlO65b8CfKb4exbm78QQ2gyBOtCYf4=3D?= x-ms-exchange-transport-forked: True 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: 6ffc4904-4778-44fc-2003-08d8fff75241 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2021 10:14:57.3930 (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: aUA2yYJl4Cahlm9oPOtsLVb251Ordbo1opYoNe+VlVf21G7ZqdnOpQj+d6Fys1ZNK7YX1tS870eJbqQspsTxPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4349 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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, It is possible the user don't know how many ops to dequeue.=20 For example in VPP crypto up to 64 buffers (vnet_crypto_async_frame_elt_t) = are wrapped into the following data structure typedef struct { CLIB_CACHE_LINE_ALIGN_MARK (cacheline0); vnet_crypto_async_frame_state_t state; vnet_crypto_async_op_id_t op:8; u16 n_elts; vnet_crypto_async_frame_elt_t elts[VNET_CRYPTO_FRAME_SIZE]; u32 buffer_indices[VNET_CRYPTO_FRAME_SIZE]; u16 next_node_index[VNET_CRYPTO_FRAME_SIZE]; u32 enqueue_thread_index; } vnet_crypto_async_frame_t; Instead of passing vnet_crypto_async_frame_elt_t Pointer as metadata to cry= ptodev, we have to pass vnet_crypto_async_frame_t pointer into cryptodev. The callback function helps parse the first dequeued metadata to get n_elts= and will dequeue that many ops. But in case we cannot dequeue the whole frame, passing the number of ops no= t dequeued yet in the next dequeue_burst operation should help us to dequeu= e the whole frame. In this case we only have to cache up to 1 frame pointer= for half dequeued frame. As the patch stated this should help cover both cases for user either deque= ue the wrapped data structure with multiple buffers, or dequeue a burst of = packets - hence giving people more flexibility.=20 Regards, Fan > -----Original Message----- > From: Akhil Goyal > Sent: Tuesday, April 13, 2021 11:20 AM > To: Zhang, Roy Fan ; dev@dpdk.org > Subject: RE: [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue > API >=20 > Hi Fan, >=20 > > This patch changes the experimental raw data path dequeue burst API. > > Originally the API enforces the user to provide callback function > > to get maximum dequeue count. This change gives the user one more > > option to pass directly the expected dequeue count. > > > > Signed-off-by: Fan Zhang > > --- > > app/test/test_cryptodev.c | 8 +------- > > doc/guides/rel_notes/release_21_05.rst | 3 +++ > > drivers/crypto/qat/qat_sym_hw_dp.c | 21 ++++++++++++++++++--- > > lib/librte_cryptodev/rte_cryptodev.c | 5 +++-- > > lib/librte_cryptodev/rte_cryptodev.h | 8 ++++++++ > > 5 files changed, 33 insertions(+), 12 deletions(-) > > > > diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c > > index f91debc168..a910547423 100644 > > --- a/app/test/test_cryptodev.c > > +++ b/app/test/test_cryptodev.c > > @@ -162,12 +162,6 @@ ceil_byte_length(uint32_t num_bits) > > return (num_bits >> 3); > > } > > > > -static uint32_t > > -get_raw_dp_dequeue_count(void *user_data __rte_unused) > > -{ > > - return 1; > > -} > > - > > static void > > post_process_raw_dp_op(void *user_data, uint32_t index __rte_unused, > > uint8_t is_op_success) > > @@ -345,7 +339,7 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t > > qp_id, > > n =3D n_success =3D 0; > > while (count++ < MAX_RAW_DEQUEUE_COUNT && n =3D=3D 0) { > > n =3D rte_cryptodev_raw_dequeue_burst(ctx, > > - get_raw_dp_dequeue_count, > > post_process_raw_dp_op, > > + NULL, 1, post_process_raw_dp_op, > > (void **)&ret_op, 0, &n_success, > > &dequeue_status); > > if (dequeue_status < 0) { > > diff --git a/doc/guides/rel_notes/release_21_05.rst > > b/doc/guides/rel_notes/release_21_05.rst > > index 8e686cc627..943f1596c5 100644 > > --- a/doc/guides/rel_notes/release_21_05.rst > > +++ b/doc/guides/rel_notes/release_21_05.rst > > @@ -130,6 +130,9 @@ API Changes > > Also, make sure to start the actual text at the margin. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > +* cryptodev: the function ``rte_cryptodev_raw_dequeue_burst`` is added > a > > + parameter ``max_nb_to_dequeue`` to give user a more flexible > dequeue > > control. > > + >=20 > Shouldn't we remove the callback completely? > What is the use case of having 2 different methods of passing a > Simple dequeue count? > Why do we need such flexibility? >=20 > Regards, > Akhil