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 1BB9943C90; Tue, 12 Mar 2024 13:03:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DE780402D8; Tue, 12 Mar 2024 13:03:07 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by mails.dpdk.org (Postfix) with ESMTP id DB81D40282 for ; Tue, 12 Mar 2024 13:03:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710244986; x=1741780986; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SGfNO6OYx3xB3RrXMslCEpOSRk/Knt3aZqsD3KIGbew=; b=dMpNYH9qgNEpfjvw/YYWoE/sygW/7vxJ0S2LtE4iKX2ksPoguQo7KUML d3ag4zZFTy+J/mWtX6j/y8pNHbXlpihNeeTv5bf0o7YGTkCtDcWGV88Uy Ft5+XuU/XSEwtB/BJmascPps2uttoSEF3epIoBHD3mln/YS1bNDva1DMc B+46zKTavtllDSu/sbtDuSG9eq8Csf7jDRhDsCEKr79Q2XMz3mFgwHiRx IMCyvM9VvhvpNL8tmy2s2uBDDj3l5zYk3YRLWN5aZcYsKva3Kf+r+ArhO gDUQrRWAlFihVFbT5tS6wIpZIfYB72asVAaEwTRelnPtQ7XVtJytfwhFx w==; X-IronPort-AV: E=McAfee;i="6600,9927,11010"; a="4801905" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208,217";a="4801905" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 05:03:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208,217";a="11977076" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa007.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 12 Mar 2024 05:03:05 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) 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 05:03:03 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx612.amr.corp.intel.com (10.18.126.92) 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 05:03:03 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx612.amr.corp.intel.com (10.18.126.92) 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 05:03:03 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (192.55.55.68) 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 05:03:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gRDSjVwvbckusIlPGVBLlzDgqjp6luGoP5bvAso1GIVjT4Jf5caeNdV7HHNgKQwOHrdp6wQpduwfRc9wu7xEs2DtIzg4t6BsGFLREUE+O6FfewXVzPNooEYadZluNu6TSIq9kLhljpEldFiE82tL9CRq6JFiT22D/9s3cAlhms3CnyXpu3nqvoODde7vxq8db1d1FiSa/NlPvq/zW8wpgxvfmzLVczISAcXWbBrYR0ccC/shw/M3btYHuBokhnVSxwknA43/FvQAjTeDov5/d5JA8TSNlotmMJeouXSN3tbose9ewHO7mYOiidgva+1AbYlPN2CC0xEAWYi5exdxmA== 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=6CJUWo29AMlDipS3NBmi51ihISL+Rf6ndsBCKaW08lI=; b=HuSIeT9bsZ9pqKa4nInWbKxbHFSngoyY2ChtCPrVwnPi5CxHbZmNjEdky/0T7W2xtOZmpw86na2B5uqD63FLgEODGPfcVyAuH+yOr1fupjc+BMofEgO1QTkt3zweeu3X3h7uaHntEiXljZV+jqUn1HH3TolGAfOU4gZb3G/r+WpUtJOwYVGw5FqJUUJbhj0S0YdNw52FQtVn15Y3QKfT/Y2wWKeIChp/Tf3sswhJFMHD5tRu7nxxVdRdA1NV1kxL5fEXKjqO2WLUc0fCb/0JjjHbVHYXIJzLnqYQL2SorAdrZUmyt6fXBDwrfSO4A+/zi1ksYiZr9gxVjO4clyZlIA== 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 DS0PR11MB6398.namprd11.prod.outlook.com (2603:10b6:8:c9::6) 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 12:03:00 +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 12:03:00 +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+MAvLpaLTkGIacnPGT5mjgAUF2vwABjax3ABNI8H0AAAVEBwAAg+5mA= Date: Tue, 12 Mar 2024 12:02:59 +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_|DS0PR11MB6398:EE_ x-ms-office365-filtering-correlation-id: 586bc34b-a24a-46aa-1db6-08dc428c5cd9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F1+7hKAIoBkFVLKvqwaUxTR6nPTLSRF47Q+5Q4oIaQakGd9IZTZnmb1ExsSzhlT1aB9ct75KDBlpN3WPCrUv4ufY/OqEqs967DW5Z0YEPcvyABh/kVHsz7EnNyBUPYwRwU5UpRjLTVy+NqgS8zwnCyrNIV0eKDQbHVkQwOvKUaLhsVRj4TtzwjH4hGue8QSYneCN9jAn4sqhcWwpgubLMbvHqVPDjVIVodKp2NgJ5SISWJyxANosPsVkviB9qi39T1anWuxJ/uT2dvH9Ue4pn5HX1EZlK3JYbg6+6o6l4C16IxUMUTv54/IqWiAx/Tdk8O44CGr0HYIQxd9Bh7hqyH+ctq5xGHOJL3gBt8RSn9g25ygk6o0M2E3u2JF6QuJC72wdfPn83nWnOaib5qIpqB2PVqH8dG3QjDTrBICvO8593oeBq+8PRRuAKqrnAI7FfF/UfHqm66MKZZ/zhnm81kR7XFLwO6vktmBNqZwLNoa9k2ins6YYbilhKRSY3hSgi0MorKBrvpaj/UnSrI53lidsOUVN124JMEepehtlb2EVwrAReTrRUaINpexScxveNqrz+Ao1ZqDnQmA8PpnCn39APMpqsOMR5iXYIH3iesmIgUS+0aWOQSsBOLTMKN7CNLOGa9INc9aDPJBqr80qZlz928I2D59ArY92YnOBfyiAW+MLux8wI76/LetLfDCVPb0cPhfZgzD7fZO61iXLauawDZfFLRQe8I280kWELl4= 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?jum6LPXluh/ahMNWpI3yZ7WF8FEY8mpDcj0fzG9tpYHJ9actTXm/QrIAM/J2?= =?us-ascii?Q?rSFOjej7M4BieB+3jFUtpVNDLsDMfV03IY3lFdOTTQFCSmIh53ny+b7U32pn?= =?us-ascii?Q?5CVo7UN+q8m1Ik8FaGcbzgHfhxyrHYMgP0Wlknil+ChRCs3uvnaMtRFZB+ve?= =?us-ascii?Q?/n/pvkMUF2mmOA5/PMP1CzMsy+KYlWmL0147t6SzolnWY0jvMFwtVr3rJzqn?= =?us-ascii?Q?QDuELj96eezLJHjuENVQgDj5vL1V+96ILc/bOc6v4eaXy0MqeYHJmsuWPH7/?= =?us-ascii?Q?gUXvmTnFq8WTMHOFrQXaure9mOuj3ZLSdCS+vyfrUPefhDYfEgiL2eFfgOez?= =?us-ascii?Q?xg79hD+6NJ33z2zF8V0a75aOFVCmlqyepAuT4QITyLDatcGyjrICq9wMiEYp?= =?us-ascii?Q?GjNwGlQRXqi/OYCOCSHTy+ER8cgYk76yN8Q0qDN5szmghY7xDG8y7mz95QQi?= =?us-ascii?Q?NN+sGZ1BA0aziZI89BotBkMl321PIPF6luz2x8CfbkdxezyohWfX+jCNeY8u?= =?us-ascii?Q?njrYuzcJLHdp6hj3OyDhvUwOAmGBEH5/nUuRt4PaThH9zQUABLq9gwem1wNg?= =?us-ascii?Q?bhcok6k320jsdzXg7TnC9GUemqfFugEXevnw02eE+Pi50hrYdxgyrwCw2cNA?= =?us-ascii?Q?a+vTmqMY0+iC3sLBUr/UqZPURUrqjEkzKbA5CzMM/ztbrGrV3ZUziuzYqGtK?= =?us-ascii?Q?D0wqV/JQ/KubzC/qGMtKDzfM0Xn/WbBIdUC+usKAq49SY7ZZLPzcfVm5gdn0?= =?us-ascii?Q?v5lRumToQC9VbkBeV76F3fO+BP856RqnfB1OCZcYhoKZYqXtJ1ZfH1aw+SpF?= =?us-ascii?Q?MLymR1InkZA7D7Pwl6QPx0z7RYY6eL1cjs+zyCaLau2wBglxnNG+qjNNpCn0?= =?us-ascii?Q?1sadMKBt4HLrAbimxPzsdm+Aa9b+accIJeFmiNpHeqinnOdx+7Yr1ImZCebp?= =?us-ascii?Q?Inc5RwKlaH0uci4A+H7B2E1QbxP8gFTIUboY6BcKrCtTTv2/jg/XajnqmM/Z?= =?us-ascii?Q?gWC3vE+TyZZzqRGhnOTIGlydHbWg4yH3QUpPOQ2U+BlRRyi/t/y8eTpiElQf?= =?us-ascii?Q?bmjPRFmGKq47P9ZU/EfUu3c5FF5HLf3W3XvVNivhXx3D9PPZ2eKis/l/xtgF?= =?us-ascii?Q?4H5cS09ENctENmJe6pxriU8YWNE/s5rnQTMqf0tyYniWwINdhtbKBJ5tkyQJ?= =?us-ascii?Q?6guFL+qdOl5cWz1sVm+xPjWmPdaYHZCHklm0n5ZJDTVvK3FOwG7OsQJcLVN2?= =?us-ascii?Q?NACkkPqh/hcVH9vkSK1dQ2Qyfm+pOmiKN7Kbmu/ZIiHTbgH9ugnXUx/TXtpN?= =?us-ascii?Q?CgcPJcR03DtiIYs/uJogGfwKemv68KKhbFasVA6OSoshbK2RahkNFb3iW00K?= =?us-ascii?Q?CV1dqFMj+Dny6nHfNkSfuFPd0Zr4JHRw35JT/NnodyMB1YSRXp7mcBQBoJhp?= =?us-ascii?Q?ZuGEN9HZkrr6PZl70F+HOdCg/BD/kP4MReZXi3xfCv8hQ0ZkhCgNLoN4oePr?= =?us-ascii?Q?4rB4kKV4RmrywwWjkneGvGDJHBzAsA/c5p66cmnYqDC05JYCvk3Dvpz7dED/?= =?us-ascii?Q?mx2TL0RCgoj34QaN+4gN2+bwS0wVtBWXVkkqp5R0moPpluMdTz0KG4qb326I?= =?us-ascii?Q?9A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW4PR11MB591137DE406BE3619A6D2873872B2MW4PR11MB5911namp_" 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: 586bc34b-a24a-46aa-1db6-08dc428c5cd9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2024 12:03:00.0058 (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: r3OwTKjat+YlkBJ84JmN0xqaNIHRf8vV0Ljp0WTGXl2IFbmEllDcRdKcYNowX02VtrDOcYzL4SRNKB7QMWwq/oD7mD9PpA86qFs6HdOJlMg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6398 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_MW4PR11MB591137DE406BE3619A6D2873872B2MW4PR11MB5911namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Akhil, Please find my response in lined. Thanks, Ganapati From: Akhil Goyal Sent: Tuesday, March 12, 2024 1:41 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, Is it not possible to use rte_event_crypto_adapter_enqueue if you want to send the event context to cryptodev? [Ganapati] No, event crypto adapter sends only ev::event_ptr as rte_crypto_= op to cryptodev and not event context. While using rte_cryptodev_enqueue() all previous stage event context is mea= nt to be lost and It would send a new crypto request to cryptodev and is not supposed to be a= ware of event context. [Ganapati] Yes, proposal is for sending implementation specific value from = eventdev to crypodev and vice versa P.S. Please fix your mail client to reply in plain text on mailing list. [Ganapati] Done Regards, Akhil From: Kundapura, Ganapati > Sent: Tuesday, March 12, 2024 1:22 PM 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: [EXTERNAL] RE: RFC: Using and renaming 8-bit reserved field of rte= _crypto_op for implementation specific Prioritize security for external emails: Confirm sender and content safety = before clicking links or opening attachments ________________________________ 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 <= dev@dpdk.org>; fanzhang.oss@gmail.com; Ji, Kai >; Power,= Ciara >; Kusztal, Arka= diuszX >;= 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_MW4PR11MB591137DE406BE3619A6D2873872B2MW4PR11MB5911namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Akhil,

   Please find my response in lined.<= /o:p>

 

Thanks,

Ganapati

 

From: Akhil Goyal <gakhil@marvell.com>= ;
Sent: Tuesday, March 12, 2024 1:41 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,

 

Is it not possible to use rte_event_crypto_adapter_e= nqueue

if you want to send the event context to cryptodev?<= o:p>

[Ganapati] No, event crypto adapter sends only ev::e= vent_ptr as rte_crypto_op to cryptodev and not event context.

 

While using rte_cryptodev_enqueue() all previous sta= ge event context is meant to be lost and

It would send a new crypto request to cryptodev and = is not supposed to be aware of event context.

[Ganapati] Yes, proposal is for sending implementati= on specific value from eventdev to crypodev and vice versa

 

P.S. Please fix your mail client to reply in plain t= ext on mailing list.

[Ganapati] Done

 

Regards,

Akhil

 

From: Kundapura, Ganapati <ganapati.kundapura@intel.com>
Sent: Tuesday, March 12, 2024 1:22 PM
To: Kundapura, Ganapati <ganapati.kundapura@intel.com>; Akhil Goyal <gakhil@marvell.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: [EXTERNAL] RE: 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,

   Any comments on this proposal?

 

Thanks,

Ganapati

 

From: Kundapura, Ganapati <ganapati.kundapura@intel.com>
Sent: Wednesday, March 6, 2024 10:27 AM
To: Akhil Goyal <gakhil@mar= vell.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 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_MW4PR11MB591137DE406BE3619A6D2873872B2MW4PR11MB5911namp_--