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 A64C543C4F; Wed, 6 Mar 2024 05:57:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32B2A40269; Wed, 6 Mar 2024 05:57:28 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by mails.dpdk.org (Postfix) with ESMTP id 9F4FF40156 for ; Wed, 6 Mar 2024 05:57:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709701046; x=1741237046; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tgw1wO7ZEv4VQcAUQ4B5DzGHmwGPVBcoNBJsUEbBQpA=; b=cwmLMGeH6Vh6h08Rdd4Cc1htUnDLr/3WBAkqLn0dB/+c70KVL/EKe+ZO cjxB7bngg0DM6mepsqDiHQxlsu1ayOnsqNtFZu6JnLiw1IQjTALUmVejv 3/kEXAJ1gA4Woz0OyuR51lg+ZDbvnhOwHqCx0TLaZSBFxN8km6Y/86ROh x4+xBZe2ZQ0AcrPzkHvnlhu9w8XzE2mDyein+wMZL+gSncrzxzWAsb9cC bnR2V0fHR7zkJxW/vDPfqPSqDQXucJkahRHd5rIfAfIvkU0S3o8fwddsV KiDYHwufjPg8yMLNuypdoB92XNsKO67we1tl7zfFTt91GQyGnE7xMnyDw Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11004"; a="7238640" X-IronPort-AV: E=Sophos;i="6.06,207,1705392000"; d="scan'208,217";a="7238640" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2024 20:57:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,207,1705392000"; d="scan'208,217";a="47153686" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa001.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 05 Mar 2024 20:57:21 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 5 Mar 2024 20:57:21 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Tue, 5 Mar 2024 20:57:21 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 5 Mar 2024 20:57:20 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yl7WPAJU5HxYz0AFLJ5G9dThUdoZXoH3+q9irMFMxNsG8qlfHuWLixZ3TPgSlJVaVEM1kKhrA5/aF3xDlq3lxg9OsZYiSeLPwk+JAW+1R1xZTkwjJw5t+avH7mO0IxX1/IbhJ6VFm0awODMBu3L+nCL9rDs/iqhauLrVZ2jAvWEbBU/Jk6xjM9sH0n8DFtqxdq2G6BgQt76ewePBGRfbAqs/87Qp/7eiLdhxMa0yLE9VqWt+jR5xCi4FsFHHVAoYfbm04IUobc7pNmAezdDqxw4zwuRV/GMaPSku4pWn3Xo3s2ZDsYX3Ob5ajkefEfr7mD5YzVvRUD9dwk5nV4gPew== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AlshF1eFZq5I7/DeL7hYxVF1SWzpTRw338qVPWNc3h8=; b=DSxw7m6iFj8QKvtj3c0Y0/5cKNBv8FC5auUwZDi8coqp2E8Ca71E8+WjSEOYnTY1AGXFf21UXsLplZSs2fhqs/kisYM8Deu5HR9/5/EC/VoPe8CXUtoB1V0KsDWpVqg9nt7bbxYBuI2KGT/Tt5TGVi8ddIWbPjs3dxkKcd46Gonuy7OlmlbwU86z3qWjB+XenVs1SWcDoT61KDDKxf3wd42E/1Akt6bu+nCgwsDTBO65BSPUyHYo2qJhpNJ8hfnBnkdak7GY8jAaQpsR8Fg62LqFTabP4EolS1z1u9Uq6Gfhp7HmOXxoMgrOz6By9+xR8iWHZiWQ89EqhMfxmWwpIQ== 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 Received: from MW4PR11MB5911.namprd11.prod.outlook.com (2603:10b6:303:16b::16) by PH0PR11MB7445.namprd11.prod.outlook.com (2603:10b6:510:26e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.14; Wed, 6 Mar 2024 04:57:18 +0000 Received: from MW4PR11MB5911.namprd11.prod.outlook.com ([fe80::6446:3cb8:5fd5:c636]) by MW4PR11MB5911.namprd11.prod.outlook.com ([fe80::6446:3cb8:5fd5:c636%3]) with mapi id 15.20.7362.019; Wed, 6 Mar 2024 04:57:15 +0000 From: "Kundapura, Ganapati" To: Akhil Goyal , dpdk-dev , "fanzhang.oss@gmail.com" , "Ji, Kai" , "Power, Ciara" , "Kusztal, ArkadiuszX" , "Gujjar, Abhinandan S" , "Jayatheerthan, Jay" , Jerin Jacob Subject: RE: RFC: Using and renaming 8-bit reserved field of rte_crypto_op for implementation specific Thread-Topic: RFC: Using and renaming 8-bit reserved field of rte_crypto_op for implementation specific Thread-Index: AdpuzBj7+MAvLpaLTkGIacnPGT5mjgAUF2vwABjax3A= Date: Wed, 6 Mar 2024 04:57:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR11MB5911:EE_|PH0PR11MB7445:EE_ x-ms-office365-filtering-correlation-id: 4b83cebb-4d67-4dc8-d6f4-08dc3d99e457 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ais6b6WXpq91zZs3JAgG4eu5K3Nr/VN6SiD5XEfXW2drV3AviFoqa4ADQ1jsYD0ZFF3arHgGCltxPIzI4QLJCAlVYJiNFdDDJdAdBtB/saWcmkLDVPDiggR4JNhwYlasNNonHr6bOGToZHBP8Y4Bf4fiNP4WAcrvXLVJm6yEaXtKK5k93GKCFADjTuxjIp4HZnvM0vP+zxZ/yEcGd4pBHNG0c50TQ9iywALBWgxy2YK4p5ycu1ax2kJeEp5e43nzL6D+9eoD1+vOJGNfnPJN1328Rr51lWIFYT0U+9yDQ0Y6WM5G7GsZSxfK2xvC7p3P5v/9j45cFBl2VkKUUFB0bPip/iNb3A9gHI7tgmPJpKyWVfF7uyC/HLQTmUKgSocI04h5ZjV0FARyYiZaBRoY6QS9gMVM5W76Q3KMh2eI9eiRA65WgXWDhDVVYt56k45y+PuUhCbW3drqsZU7RvqbShu95gyZPtP5Sht9Jzw245e6xjNT0YfZarZZbpMIzRXj1qleNbcR108fj6RBeB/hsvqCgeUJtuy17yWeX4MWbUROTHSv9DNDiuP/HKJTM5uXGVpDPJbIsXxOOLOftE395l+svJKHTxzAN1FTnoevTeOCpCQEwBDyKT+b6gZdyd0jwOlGlMLE64dTGYbP8fNkGiXJGLwKWFVz3CFB5PR4mAuaXNU87AHosqRNVZZzTwGpst+1MwHRphh2sSH0SWLJ6UqdAJGqW/ZoFe6FXvx17Po= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR11MB5911.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(38070700009)(921011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?dojndRBaLh2aSIGxwdWbjnDTNMxvk3uMVsE+BLd41o917H+jA7ySxpUleVhI?= =?us-ascii?Q?q3p7xqR+y0/sECl3+Df2F1hlYX5zs8XYPjYnTtlZi2PuXp68Yf5aKh8gOjiS?= =?us-ascii?Q?FVe+T4Wzxpn/3A2DG5HU6R4HN3qepo1eTFZQqCjLLXaeJjIj32GFglEYH/o2?= =?us-ascii?Q?nBt3WFaZgDALuwCEBSEKA8sRf7WfOFMMe48+oBh1nybSQWUnrG1VCGcJkFiU?= =?us-ascii?Q?Sd1A4on9PSOVWfVNlIfZD28znI1nOWskx79sAx88po6zxyblGScCkj2UWQD8?= =?us-ascii?Q?+Hptj2tqFvzC3sdzptZvufuEW0ClMw7Mzji2jqw/0noTYaCL3fi7UhfLlY4w?= =?us-ascii?Q?NyT069eKMjKY1Nz5ZKjdxEOI8mPRR9XLf7MsIfG+b3UTngKOiCrGdmOMYEal?= =?us-ascii?Q?J0KgG8n+9FVO42TMcm9zuShoxo6poU4Ldzv398D5XgTpqH+JWgXwOmL/LE5C?= =?us-ascii?Q?Ut23BQnjEluaxZzkiXaWkNPRLOKlev6wqmzfgcty7cVigz5P/43hDBMlGSDx?= =?us-ascii?Q?Hwr3ycILrAnma3W5Bh5NaGkIHzDGXgzdnB7fOjP/4nKJXOJpi0LukRRB36sK?= =?us-ascii?Q?wf+OYNa3F19ZJU02quVJc2E8viLiW2R6peNfQosZrWmJazkiXYdXYNKr4Meo?= =?us-ascii?Q?cPYduLrfxvo7CIzUCDNX5gScK7VBma1fbmzJc/iHXp2XyF6GLc6uJpXAmQHb?= =?us-ascii?Q?yNqRn2vK/MIN3G4nT6LtSLXOp0jRqYXO5zIJP319uIqw2XgJMfTjsLYzQoaj?= =?us-ascii?Q?Xbbw8VcWyppev58b4YrrryCRqpyhVP+1T0EEH53hry74K9L7zEBXXL5EpNhD?= =?us-ascii?Q?5ipFoZksr/GFT16Q49WZCuPQOoY3L8efVUQWeVAua7xAr/eiEIvK+ilhAXWv?= =?us-ascii?Q?Y42S46tJl1XKtYEtJLIVdf1IWkWzMZbSn0heqXhpOcROlNn+ZmqgDyt5VaOr?= =?us-ascii?Q?sp49qP9WGPDYcXk3lSdcY7kAfcaQJ3iVYJD5huIsXzSUp1Jk6xvCovddtU/y?= =?us-ascii?Q?SAOfGKlPa6sDXnu3pDLS5NGAAP7x5D3KJS4ffav5n8LMdoCBpclZDBiz1ysZ?= =?us-ascii?Q?uR9vAGB9ImoD09FUOeZsWHrHKZex4BSvlImfn6oADXt9g9WBXwvt2K/NyMBQ?= =?us-ascii?Q?GXeqOFozk1ESEl0bDPZotWvheSen5qFbgE0bFIgmH17uWe5iWpAUgNcD8Zjz?= =?us-ascii?Q?8Pj8oANhguJ5otEDdkMqvtoTKIJijbYKJslIGolyTsv5vMTbWL4sPwIqNe6K?= =?us-ascii?Q?iovwwnvg8JH1s/ree1qAu64Ylps+HROpM778cJWUWupQ6IFcCdZh31wiuaU9?= =?us-ascii?Q?mBQ3dJ6UAbY9NnER9Gjmo5NPkTV9g5bJNvCzKpFyvw5VjIGO1I0Nc6FFLUas?= =?us-ascii?Q?EZyuB+emS8JtuT0L+VirVGZBNcan5i/i6YuIv6dmKBqsTHBe6Jo0OJ6TiJiA?= =?us-ascii?Q?ggSlPC5icTSfzavP89e0glal99bY4kc5L0jXMDZPXCTpt/f5T1hRIt8/ZvLD?= =?us-ascii?Q?25BfYIZkPtE9qXu8fvV2Jglkf5/NrycetXtXvFrR8hOzUNu6f+dOtc16VqMI?= =?us-ascii?Q?F/c1jGfUewbBX9F9Fb36FVXp8tYQDxXfiuxlLCe+g33BMjVLmJLjDA/a55RG?= =?us-ascii?Q?bw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW4PR11MB5911791C90E5AAF9AE0458ED87212MW4PR11MB5911namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5911.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b83cebb-4d67-4dc8-d6f4-08dc3d99e457 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2024 04:57:14.9903 (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: sgP9wpuZ9wq68erpLclIWuQ5s5jcFQQa4nyQf+skH9uHsu1bmIFEhTyjwUhZD7pFnl5sHJ23UaInRRKoII8gqMHqr9xvo41C0iU9cynpIhA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7445 X-OriginatorOrg: intel.com 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 --_000_MW4PR11MB5911791C90E5AAF9AE0458ED87212MW4PR11MB5911namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Akhil, No changes in sequence of API's by adding 'uint8_t impl_opaque' to 'str= uct rte_crypto_op'. It's required in case application/event dispatcher passes some implementati= on specific value in rte_event::impl_opaque, to restore the value back on to rte_event::impl_opaque after enqueue to and dequeue from cryptod= ev. Here is the pseudocode for one of the use case Application/event dispatcher passes implementation specific value in rte_ev= ent::impl_opaque. struct rte_event ev; rte_event_dequeue_burst(..., &ev, ...) struct rte_crypto_op *crypto_op =3D ev.event_ptr; // ev.impl_opaque some = implementation specific value rte_cryptodev_enqueue_burst(..., crypto_op, ...) ; // ev.impl_opaque is not= passed to crypto_op With rte_crypto_op::impl_opaque field which is unchanged in library/driver crypto_op->impl_opaque =3D ev.impl_opaque; rte_cryptodev_enqueue_burst(..., crypto_op, ...) ; ... rte_crypto_dequeue_burst(..., crypto_op, ...) ev.event_ptr =3D crypto_op; ... rte_event_enqueue_burst(..., &ev, ...); // ev::impl_opaque value is lost with rte_crypto_op::impl_opaque field ev.event_ptr =3D crypto_op; ev.impl_opaque =3D crypto_op->impl_opaque; // implementation specific value= in rte_event::impl_opaque restored back rte_event_enqueue_burst(..., &ev, ...); Thanks, Ganapati From: Akhil Goyal Sent: Tuesday, March 5, 2024 10:18 PM To: Kundapura, Ganapati ; dpdk-dev ; fanzhang.oss@gmail.com; Ji, Kai ; Power, Ciara ; Kusztal, ArkadiuszX ; Gu= jjar, Abhinandan S ; Jayatheerthan, Jay ; Jerin Jacob Subject: RE: RFC: Using and renaming 8-bit reserved field of rte_crypto_op = for implementation specific Hi Ganapati, Can you please explain the flow with a sequence of APIs to be used. Regards, Akhil From: Kundapura, Ganapati > Sent: Tuesday, March 5, 2024 12:44 PM To: dpdk-dev >; Akhil Goyal >; fanzhang.oss@gmail.com; Ji, Kai >; Power,= Ciara >; Kusztal, Arka= diuszX >;= Gujjar, Abhinandan S >; Jayatheerthan, Jay >; Jerin Jacob > Subject: [EXTERNAL] RFC: Using and renaming 8-bit reserved field of rte_cry= pto_op for implementation specific Prioritize security for external emails: Confirm sender and content safety = before clicking links or opening attachments ________________________________ Hi dpdk-dev, Can 'uint8_t reserved[1]' of 'struct rte_crypto_op' be renamed to 'uint8_t impl_opaque' for implementation specific? An implementation may use this field to hold implementation specific value to share value between dequeue and enqueue operation and crypto libra= ry/driver can also use this field to share implementation specfic value to event cryp= to adapter/application. 'struct rte_event' has 'uint8_t impl_opaque' member struct rte_event { ... uint8_t impl_opaque; /**< Implementation specific opaque value. * An implementation may use this field to hold * implementation specific value to share between * dequeue and enqueue operation. * The application should not modify this field. */ ... }; Event crypto adapter, on dequeuing the event, enqueues rte_event::event_ptr to cryptodev as rte_crypto_op and converts the dequeued crypto op to rte_ev= ent without restoring the implementation specific opaque value. By having the 'uint8_t impl_opaque' member in 'struct rte_crypto_op' as diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h index dbc2700..af46ec9 100644 --- a/lib/cryptodev/rte_crypto.h +++ b/lib/cryptodev/rte_crypto.h @@ -146,10 +146,13 @@ struct rte_crypto_op { /**< TLS record */ } param1; /**< Additional per operation parameter 1. */ - uint8_t reserved[1]; - /**< Reserved bytes to fill 64 bits for - * future additions + uint8_t impl_opaque; + /**< Implementation specific opaque value. + * An implementation may use this field to hold + * implementation specific value to share between + * dequeue and enqueue operation. */ + which is untouched in library/driver and rte_event::impl_opaque field can b= e restored while enqueuing the event back to eventdev. Also crypto library/driver can use rte_crypto_op::impl_opaque field to share implementation specific opaque value to the event crypto adapter/appl= ication. I look forward to feedback on this proposal. Patch will be submitted for review once the initial feedback is received. Thank you, Ganapati --_000_MW4PR11MB5911791C90E5AAF9AE0458ED87212MW4PR11MB5911namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Akhil,

    No changes in sequence of APIR= 17;s by adding ‘uint8_t impl_opaque’ to ‘struct rte_crypt= o_op’.

It’s required in case application/event dispat= cher passes some implementation specific value in rte_event::impl_opaque, t= o restore the value

back on to rte_event::impl_opaque after enqueue to a= nd dequeue from cryptodev.

 

Here is the pseudocode for one of the use case<= /o:p>

Application/event dispatcher passes implementation s= pecific value in rte_event::impl_opaque.

struct rte_event ev;

rte_event_dequeue_burst(…, &ev, …)

struct rte_crypto_op *crypto_op =3D ev.event_ptr;&nb= sp;  // ev.impl_opaque some implementation specific value

rte_cryptodev_enqueue_burst(…, crypto_op, R= 30;) ; // ev.impl_opaque is not passed to crypto_op

 

With rte_crypto_op::impl_opaque field which is uncha= nged in library/driver

crypto_op->impl_opaque =3D ev.impl_opaque;

rte_cryptodev_enqueue_burst(…, crypto_op, R= 30;) ;

 

…

rte_crypto_dequeue_burst(…, crypto_op, …= )

ev.event_ptr =3D crypto_op; 

…

rte_event_enqueue_burst(…, &ev, …);&= nbsp; // ev::impl_opaque value is lost

 

with rte_crypto_op::impl_opaque field

ev.event_ptr =3D crypto_op;

ev.impl_opaque =3D crypto_op->impl_opaque; // imp= lementation specific value in rte_event::impl_opaque restored back

rte_event_enqueue_burst(…, &ev, …); =

 

Thanks,

Ganapati

 

 

From: Akhil Goyal <gakhil@marvell.com>= ;
Sent: Tuesday, March 5, 2024 10:18 PM
To: Kundapura, Ganapati <ganapati.kundapura@intel.com>; dpdk-d= ev <dev@dpdk.org>; fanzhang.oss@gmail.com; Ji, Kai <kai.ji@intel.c= om>; Power, Ciara <ciara.power@intel.com>; Kusztal, ArkadiuszX <= ;arkadiuszx.kusztal@intel.com>; Gujjar, Abhinandan S <abhinandan.gujj= ar@intel.com>; Jayatheerthan, Jay <jay.jayatheerthan@intel.com>; Jerin Jacob <je= rinjacobk@gmail.com>
Subject: RE: RFC: Using and renaming 8-bit reserved field of rte_cry= pto_op for implementation specific

 

Hi Ganapati,

 

Can you please explain the flow with a sequence of A= PIs to be used.

 

Regards,

Akhil

 

From: Kundapura, Ganapati <ganapati.kundapura@intel.com>
Sent: Tuesday, March 5, 2024 12:44 PM
To: dpdk-dev <dev@dpdk.org>= ;; Akhil Goyal <gakhil@marvell.com= >; fanzhang.oss@gmail.com; Ji, K= ai <kai.ji@intel.com>; Power,= Ciara <ciara.power@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Gujjar, Abhinandan S <ab= hinandan.gujjar@intel.com>; Jayatheerthan, Jay <jay.jayatheerthan@intel.com>; Jerin Ja= cob <jerinjacobk@gmail.com&= gt;
Subject: [EXTERNAL] RFC: Using and renaming 8-bit reserved field of = rte_crypto_op for implementation specific

 

Priorit= ize security for external emails: Confirm sender and content safety before = clicking links or opening attachments

Hi dpdk-dev,

   Can 'uint8_t reserved[1]' of 'struct rt= e_crypto_op' be renamed

to 'uint8_t impl_opaque' for implementation specific= ?

 

An implementation may use this field to hold impleme= ntation specific

value to share value between dequeue and enqueue ope= ration and crypto library/driver

can also use this field to share implementation spec= fic value to event crypto adapter/application.

 

'struct rte_event' has 'uint8_t impl_opaque' member<= o:p>

struct rte_event {

        &nbs= p;       ...

        &nbs= p;       uint8_t impl_opaque;

        &nbs= p;       /**< Implementation specific opaq= ue value.

        &nbs= p;       * An implementation may use this fie= ld to hold

        &nbs= p;       * implementation specific value to s= hare between

        &nbs= p;       * dequeue and enqueue operation.

        &nbs= p;       * The application should not modify = this field.

        &nbs= p;       */

        &nbs= p;       ...

};

 

Event crypto adapter, on dequeuing the event, enqueu= es rte_event::event_ptr

to cryptodev as rte_crypto_op and converts the deque= ued crypto op to rte_event

without restoring the implementation specific opaque= value.

 

By having the 'uint8_t impl_opaque' member in 'struc= t rte_crypto_op' as

diff --git a/lib/cryptodev/rte_crypto.h b/lib/crypto= dev/rte_crypto.h

index dbc2700..af46ec9 100644

--- a/lib/cryptodev/rte_crypto.h

+++ b/lib/cryptodev/rte_crypto.h

@@ -146,10 +146,13 @@ struct rte_crypto_op {

        &nbs= p;            &= nbsp;          /**< TLS rec= ord */

        &nbs= p;            &= nbsp;  } param1;

        &nbs= p;            &= nbsp;  /**< Additional per operation parameter 1. */

-        &nb= sp;            =   uint8_t reserved[1];

-        &nb= sp;            =   /**< Reserved bytes to fill 64 bits for

-        &nb= sp;            =    * future additions

+        &nb= sp;            =   uint8_t impl_opaque;

+        &nb= sp;            =   /**< Implementation specific opaque value.

+        &nb= sp;            =    * An implementation may use this field to hold

+        &nb= sp;            =    * implementation specific value to share between

+        &nb= sp;            =    * dequeue and enqueue operation.

        &nbs= p;            &= nbsp;   */

+

 

which is untouched in library/driver and rte_event::= impl_opaque field can be restored

while enqueuing the event back to eventdev.

 

Also crypto library/driver can use rte_crypto_op::im= pl_opaque field to

share implementation specific opaque value to the ev= ent crypto adapter/application.

 

I look forward to feedback on this proposal. Patch w= ill be submitted

for review once the initial feedback is received.

 

Thank you,

Ganapati

--_000_MW4PR11MB5911791C90E5AAF9AE0458ED87212MW4PR11MB5911namp_--