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 860A543C8E; Tue, 12 Mar 2024 08:52:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 71A37410EE; Tue, 12 Mar 2024 08:52:28 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by mails.dpdk.org (Postfix) with ESMTP id B0F57410E4 for ; Tue, 12 Mar 2024 08:52: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=1710229945; x=1741765945; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=U4suDxd4PrapY74F4mR18ZKpB7W5nCqMTkcN1+/JnfI=; b=VODJ4coTKVpnQoHbY1sMJ/4UQ/gguOs/DD1GHSRaVtvURYuxBSM8/sP1 dk/oDgnFOBG+2SiLCgGkby1Ffk4SHbRx100Tehe/neDk3D5qgzrEyb7Dz MT6Dhuk927cdMQ8vMcXqn1hYaLPBR1Y4EoWJz9xcAdHhqqEiom15/zG7T 0wFiwOGVC+cfGdvc5/6HjM5XBI/tWMU8Ljrl7hw4ogq8J9Uf645m65nZO 7tLh0ERPdpH8DSOJ4LSZOx/X0rSOj52lym+yf46mJDqoA55J3igMLo6Fz EzfDWY3mZ9rR86yI+PARaDfpH4q8FeGoIi3Qs5z+Fx4nw47Y10hZ7iq0b A==; X-IronPort-AV: E=McAfee;i="6600,9927,11010"; a="4782775" X-IronPort-AV: E=Sophos;i="6.07,118,1708416000"; d="scan'208,217";a="4782775" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 00:52:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,118,1708416000"; d="scan'208,217";a="15946308" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmviesa005.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 12 Mar 2024 00:52:23 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) 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, 12 Mar 2024 00:52:22 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 12 Mar 2024 00:52:22 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) 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, 12 Mar 2024 00:52:22 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) 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, 12 Mar 2024 00:52:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fkBPomX7JFLbEVG/csHv9Z99X5qqC9pcnuPsXFUUczX4LHPj/vKOADXiATiwB3BQ3BG7CHFrxZ94+H5LxG6GztaxXT7PIRXDkWJFyp6y7+g2A+Rmf8RWbLkNTZed7X9ITS80poVJ8c+mVAn0RoRLz+oIWVoego4ZRItP3WAeI/nT79dgVLw6YYMYVjknwDh97KYtOMVSIOH3oWV+kJihRko2WhFm6YEUxRRIRE48OEWE5Dj2ioz3SkJXD5FXw0UiMJ2i1VnNLMRfcIJXJlVzfnxJNth90a8qtPlaC4bVO2X9AXrxb+htIt9U7hSX1OqjAnFuVXuYLbd68ZdhipH6Fw== 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=chjos/tn0feQJw8xeBZZasUxiFzO3333HTCvCVW5drw=; b=jDgohMM5i9rX/YllIwDhicWHaAHVcziXGlQ1XT+0I4/znqtZsZZeXNzYHY7pELDyiElIaa90Apf8nmTzRrtcTIKcCV5qLJw3vqez1QdgYZxnpXQRizmmATRc3oDPSGeLkLdbVTL5xwFF/jItaCIxU0eNh6bE8Zqzjmxh/HFAPEj46/mQD3N7/BeImebiPbnjKhraFFwnE0vfna6Z+AqeXFsT3edAjIuScOGkCqPNdBU3SeBoBTZDr3EFsfpXmw1nHCXobq/gpV0tAweLnddzk2czVhw9lOZ1U659K/xZGo/uPvY7SMyFI9p1Aoybuor2j7C00ixRXSt8HvRaDN0vdg== 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 CY5PR11MB6414.namprd11.prod.outlook.com (2603:10b6:930:36::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.17; Tue, 12 Mar 2024 07:52:19 +0000 Received: from MW4PR11MB5911.namprd11.prod.outlook.com ([fe80::6446:3cb8:5fd5:c636]) by MW4PR11MB5911.namprd11.prod.outlook.com ([fe80::6446:3cb8:5fd5:c636%6]) with mapi id 15.20.7386.015; Tue, 12 Mar 2024 07:52:19 +0000 From: "Kundapura, Ganapati" To: "Kundapura, Ganapati" , 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+MAvLpaLTkGIacnPGT5mjgAUF2vwABjax3ABNI8H0A== Date: Tue, 12 Mar 2024 07:52:19 +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_|CY5PR11MB6414:EE_ x-ms-office365-filtering-correlation-id: 5a952c97-6a19-4138-9bd7-08dc4269582a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 29sMU1ZBSuEzM7fubDd3E+kDNHUtv1MWJRBeNS40eVSjdA/ktcXqHRqby/hJexI4qYhMFisEt4jPW8p5yWaZcLSgIyjzMgGCC1CaMhd5vJRI6vYWuuJ5uUhD2JoOHdH0KCa+0cqPpNc9EyI7BL8vJrkyK77401FLyDIrPQHOYdy055IW/XwFIE8t7BoygiVilj3rkH5r9rJEMjtwjNXRS56o/ij2TtCeozYT7Y9pf8CxARlm829i14u65wAzLeQIQ2IsNFsh4Skdzf1BDNkQ70mM1mzahSJX71/ieGpYXBnbJ4oJuyBaGgVl4AmtoMWTu0wbwvz0ps8amGkIqnAzMTIPeMDZyLbKnp4sV25FoMAjA50/eNKKasLNhLaxrOPzJi95PWDqHvslR6CpaaRithVQ214FQIR64EJjwu23w8gJcKxRatk5wQYlE1qPu0aGkXMsI7Yb7J1GZDbok3bcDbngl8ZOYihklUh3/bYDOSYzsJgiNpbHRN1WMDBdQDWExRDBtVVd1ua+0M0JIv1h/R54bdaoxSaAfvI265vU+w1JqROqqM2w6fCIdHJiXXR31siPD9QCnLqaZBdyptidOYB7YKTmCgeba8cGpW6W9G5aTh0jZZfwf2uFfx4IOWAp82UUD6MEj6gSRmuxX7bXdyKVxTdYJt0CPviO8FCR+RCGMcDN5COAE55B/rauoG391m2UuNdWWrPPwYrLFgr1eGDD5i++xUk7JCCM0XiYUys= 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)(1800799015)(376005)(38070700009)(921011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?3VspiAje9+w5JTxwiQHLhDhpbVeo4u6U8lSalXJZzRMRrsIFp7tbQUL3XRom?= =?us-ascii?Q?yaiDNMMVmNbVrnfcz0+oA7yGSqzdLbaDaIje2QiKoq9p12rFLAGfw5Q0aeT3?= =?us-ascii?Q?N5niUAqaEngAP2EylgxI30o2lFLOKkffY3+ASb30FIcKuel2ECP4HO4RB6p6?= =?us-ascii?Q?aSfrrjgvopDaP49Mgcqq1DOOrb88MgaEv4iWm9a0OJcYI2yhsIJYqooTVavV?= =?us-ascii?Q?aV3sJNhFug0VStvssQg4wK02bfyJxloCysqj5Cdlhqe32AttvwIMeSwowf1Z?= =?us-ascii?Q?3mUEXNE5WEaSxSA3SDwkUVXDNmuTrgT/WNPBJX2iT9iKO45qzVSo2UFCIyk3?= =?us-ascii?Q?Im7cnsWyGDdCm6PtxD/U8jSvQag3WZ6J7FzkBvU/l8Jr392dXAyXLo3u/o1p?= =?us-ascii?Q?60Ppoj1MxbM9vVshoJlR9Dej3rqBWeZOBuCvwOCD4l9mfIpFRKV/32HO/a2E?= =?us-ascii?Q?Txp7L3JLM0X85V4tpgcv6IH27JuOGmLwFT906LFnPTSOi83iy5mlZXT/BQ7+?= =?us-ascii?Q?8e1IBvutmcQCbTqEpYR89+FZ5KD2ejtqHjT8NbYE28eve3//AQuNeu752iLl?= =?us-ascii?Q?LlFfMHwZ8DtmszSBCmXz5TFF/m7L4V63/80xFU5vz9E7A4PAzJvdZKKsWoGD?= =?us-ascii?Q?P4A/ako2xOWKFY5Mk048EHRb/vNUfHvoJ0CyTfnTtZR03fQFgDuwbAWtVkGX?= =?us-ascii?Q?+3Zy2z5qklF9tW1iJ/MpQBWg565bAf8WFoJcq9M3ocyadjFiiQAD3/qqjqEo?= =?us-ascii?Q?/TWXfTM+sDGlac9jqErVFym9yaZyvVO9+5ZkAXLFnHvMq6Ggvq6AnFxZt7LQ?= =?us-ascii?Q?3xzxPNGL4RjVrE1Ju3p9ly9O/RzrLvFyQQaIWQKsjd8bDAKT9CfLz4UCuH0n?= =?us-ascii?Q?exiee2MOPaaZF1djhRvCpLeYpKlPDkB+a2lc2xCk7X2yDwT8Ht7iDX37xDP0?= =?us-ascii?Q?I/c07BFmgOq5giQLWzePrOT1tj+2rv5zxDdBOHdzMpkLuNqe4meefg+1SUXg?= =?us-ascii?Q?p+artoi6CTdM02M2FsH7MJLN3tx+gmi3NdS5vDwX6RjPhUK+NGa4/XgCVYei?= =?us-ascii?Q?grBzJaw42BJr6TYA2uUYuQm17NBvo6Ap9FlXzYljec+CpoYY4OX2YA4W7+ir?= =?us-ascii?Q?oiQLlVA+orEVVZeowbO4ywmxaohD6w1cDGYPDfD11bK3+NrMJ7kggjAAu9j9?= =?us-ascii?Q?KH4z1u1pJk3HmyVPFY5tvwSaSFj/Xbx5dAfT3sfMjL9Bf+NZSE5t5m6IwxJa?= =?us-ascii?Q?tB9mLWkXlkjKVb/fWdzAsnhdq3c9BSCq3z3QUtmroFViqjuqR5nvunhon//w?= =?us-ascii?Q?dyjaY8gilP/VAL1SZmInpsVFdENmz3EmeiF9Wy0ZGEHBylI6kRcNl1zDwoXT?= =?us-ascii?Q?2mfxQcuAd2Jsvm3eLfirHIqOabtvTE786yyVApAzJc0aED0AYt086lgQ2JH/?= =?us-ascii?Q?pOAsRq/78aED9CHE/O2LaY7OjPBuyjRT+csE5JYJEnuxuh2ds69/L79NQe42?= =?us-ascii?Q?pdqNwIRyVrF3LlaIPGQu5Byc4wBUfqqcxEhPMZBARbCx3gc4gcMlWSgxHZJI?= =?us-ascii?Q?UEqZw2i1zLEM7EP2oNeeXL8YsvKu7ZisgaZ8zHrHQBkEODIMV5sVPICnUc/B?= =?us-ascii?Q?rg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW4PR11MB59117DFA9E406FDA75A94DA0872B2MW4PR11MB5911namp_" 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: 5a952c97-6a19-4138-9bd7-08dc4269582a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2024 07:52:19.7765 (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: bi40K72EeYYaUiDIGxRZaYEhYHTIZVcpDLmLbcHgeYdiM98iTKr0dh03IojrTj7pLLLktNBSYICBB6Ev5XYuqtieSMNusa1KZq6nbMRi2us= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6414 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_MW4PR11MB59117DFA9E406FDA75A94DA0872B2MW4PR11MB5911namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi DPDK, Any comments on this proposal? Thanks, Ganapati From: Kundapura, Ganapati Sent: Wednesday, March 6, 2024 10:27 AM 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 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.os= s@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 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_MW4PR11MB59117DFA9E406FDA75A94DA0872B2MW4PR11MB5911namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi DPDK,

   Any comments on this proposal?

 

Thanks,

Ganapati

 

From: Kundapura, Ganapati <ganapati.kund= apura@intel.com>
Sent: Wednesday, March 6, 2024 10:27 AM
To: Akhil Goyal <gakhil@marvell.com>; dpdk-dev <dev@dpdk.or= g>; fanzhang.oss@gmail.com; Ji, Kai <kai.ji@intel.com>; Power, Cia= ra <ciara.power@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kuszta= l@intel.com>; Gujjar, Abhinandan S <abhinandan.gujjar@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 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-dev <dev@dpdk.org>; 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: 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_MW4PR11MB59117DFA9E406FDA75A94DA0872B2MW4PR11MB5911namp_--