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 898F843C8E; Tue, 12 Mar 2024 09:10:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A68140E40; Tue, 12 Mar 2024 09:10:41 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id B454640DCE for ; Tue, 12 Mar 2024 09:10:39 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 42C7X1xJ004858; Tue, 12 Mar 2024 01:10:38 -0700 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by mx0a-0016f401.pphosted.com (PPS) with ESMTPS id 3wt54n2enk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Mar 2024 01:10:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WC4pB9Q8nEn4HQufEeFmuwhuyhUNajzjz6H2XEgblOZ5K1Bz1kuRXO71OB+Xx6yXSHtGedIZtr1CIJRiHkQBIWfadNPIjmkWmRuO5AQwGe8wKlNSoCyY1rbp1nZbfHxi88c9gRvVnqRgsrzw7qIXQIpJ0JeFCQRZChVX0+vXkOBzU9Kxu4xSds0+PnQZEM1Epo7GShvPfVmxwjuopxxeipUditkr0qBBtjc8O9aZVGV6dK/nIrWVBJr2ntC6y9ASGLI/TcGyEFaF2szcVMcvYlK8WPasY6/9evtapRORsHyGgxeZJHSWUAprxDsE4JQKJhy3520whFanDfqFq4dqTg== 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=AdcRcW13mv+7a8zyTlpVuSbLRBLEAnQmbXoasRihHyc=; b=RZJI96hsKOS5C277mZpSzGvpzOaUH0fOrnYth4zOj+SOzBkcjtG9ryLsNkHDPwcX5cH6FlmSAbpDCqMgYao9WDfENeHEvc9LvYyaj8e2rlSnWQfFdJqCirIITuXAgX1rBrh/kBYyvOFP4RTII+pYPoY9A1icHGkX7OHDszAjdBvTwyuKKAtDRXdSlgbxcwGC+fL0LfmsfGzM4NuLAvIyzUn6nA6zoDQtntF+jyRbd9i5eYqQFyomPOdkDNDKC3rqbFJGk63aEco4oi3DrWMshiu+Kae6eqRZrBaIK56/cScXHbSYFTb6TEEpcESkU8tC+hLI4cHEzwTLmimIDLbhnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AdcRcW13mv+7a8zyTlpVuSbLRBLEAnQmbXoasRihHyc=; b=mCsBrfF86HGC7s7ZqkJAstKuStIcYO+WFGzot5yq5bMAezG5xw+VPC1/hJk01LqQEfvke1Tjg7wIWV6gYFTYXyYow6jokXJH11/dqo+XL2RYb/obN9ZrZq8kuF2x6R2iS6eKHgDHMTxHHW4FSlwpHhd9zHCT2MEpf7YXSUHb1WE= Received: from PH0PR18MB4491.namprd18.prod.outlook.com (2603:10b6:510:e6::13) by SJ0PR18MB3993.namprd18.prod.outlook.com (2603:10b6:a03:2e5::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.36; Tue, 12 Mar 2024 08:10:35 +0000 Received: from PH0PR18MB4491.namprd18.prod.outlook.com ([fe80::8747:980c:94d9:c0e9]) by PH0PR18MB4491.namprd18.prod.outlook.com ([fe80::8747:980c:94d9:c0e9%4]) with mapi id 15.20.7362.035; Tue, 12 Mar 2024 08:10:35 +0000 From: Akhil Goyal To: "Kundapura, Ganapati" , 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+MAvLpaLTkGIacnPGT5mjgAUF2vwABjax3ABNI8H0AAAVEBw Date: Tue, 12 Mar 2024 08:10:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR18MB4491:EE_|SJ0PR18MB3993:EE_ x-ms-office365-filtering-correlation-id: 110372d5-9f5b-4f62-f062-08dc426be557 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jYDi/AUscxhreu3QvUrT4kE6XjtBhp0t54QKlbQ9Zv52LHNHNxGGfk09dsCb2dTQHMgMCUUhhQiBxL5GCmGy94ReZ7E0X+sIXUstRbdTFAkVK5BT4zhKx2WiiRCw1viBovk2gApAyaiuLgdyNtVOl7bs62zY/oZs+VRp9Hu7VLxoDf7/VJN8Jt0BS7uKz/+KHFxPp3En2Fu/qEuydp5E6/Gd/dyrW/5Vvmtanfl920M9jL+kldGO5xS1x2y6oI69ZvjJ23SKW90FhI2CjHikynBmJaV9RDD5Isainqgc9yzZB5JvmvJgv4EEc+NesP3qzBNSveWXciEeO8AsxlVSNi5+RLgAoU4YmnceFdoQ6gBFoB5yPU4IojVCULQiYLZbW8soqITaZDIQ1cKR5sSUE5KI4rCiUsEFZW8uIJ+1+9MZOLQf+7JZGF2+X1UZPW374if8VI0f6u4rNeKW5ath1M0SAmTdjNSH2ym2j4Z6IEhfPbdWNjRPGIFhAlWt+PsTX24MLFU86OBZ8EWw7wWJ5nNDCziEs5V3aCWa2oWctRPzBL0mAdQzUG9/JPMiVav+F6nUipi6AHfXiggzQcQnt45lZe5FjdgTjcezlME3Lg5Uu5/POj+lqChnZCv+i7g3RuoG4HoQcuk85I5enrOdj9gX5GLe2Pb9ay7D3gXG9B2F1EWxHT2YisKwR67VJwQH8UM5KnBTeb81MUCgzaB6yCWZ9VX3mBpTuGovDtCRzbM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4491.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(1800799015)(38070700009)(921011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SeXWODrI6HB9cdUskHm7CtHY9xVEyNuR1Jzeg5X/g/9HaUdFJ4qRguNUKoxl?= =?us-ascii?Q?5RH3n9YoNO2iGN518UdsgsgOki4e/zwLIPWjj9iPuiyiFDzTutyBTRNo7SLK?= =?us-ascii?Q?rwhvtiX7in2gQb0TibsWsRLP3oEcdgBpe3/HrOkzzkKTUuJ/36J2M9ZJxICr?= =?us-ascii?Q?6zGB7lCkEjSX28Atb/KS7hD5YtHZbJzHHKYpCTLxwFUE16el/9rPGfnSeFfF?= =?us-ascii?Q?nCHoqm9Bzq1ZrFnaEZGboxv91kQfuCRwdOi1mRLxDy6vn3T8xi0UYcqy0Co7?= =?us-ascii?Q?YNWl0ibxmXKFDtwazY7ytC//QfEwo5jDaykGIdfSL6iRmCp6GbDLFk4OQmd1?= =?us-ascii?Q?Y/SlkOayk8kp01CdcFDY47/dQjmYztvaoX6dsWAf3cnRaNjarkhGJa6zHO6d?= =?us-ascii?Q?636PJRpDhEmRUeIKncqjNO+MjKsvPiJ1VaS1+b9/IjhsXfM9HIUYhrYvm/u4?= =?us-ascii?Q?s+yoz5jeebbLvwce/eUpuX+mAOh6eqZgoPvirG6h6oe/fxC6FOevzObW9jlY?= =?us-ascii?Q?d6OSpkJ4DBDW5fPEkqlhJfRDtCDnsIs4ZtjsNZCGWnp8mpsg1SlaPuUED3VU?= =?us-ascii?Q?4vC/3krIOWOpmehSe1N9oswI1oslBTrRaq/y8PJ9zn7Se8Ebi9AopevKHeM2?= =?us-ascii?Q?FATyQpA/1wsJssySyeyKyT3OZ0nS2rEtciuJgKIxt4gTilEQJ7R1Z4evEkck?= =?us-ascii?Q?P61PA6p6DS3mQJSl2kdoWNjdX/yYJx7HxKVPL9S6fTM7UobERE6XZmvf+yPJ?= =?us-ascii?Q?/A9ujPIPRK0mEIlSE/XOx4W9h16Xq52acX3b71sGGVzazgQ0jUdgegqN8rij?= =?us-ascii?Q?fHr0+FQXU1NDyoFwxRIMyUM8sw7EzEV/fqIhR1oMp/qEJhMqZFOo4ShCs+4D?= =?us-ascii?Q?YweYDMYNP/cNB0hBHAJzCBuAeV4grefiLrdN67etTcZeonmBi8IHoxaugyfn?= =?us-ascii?Q?PjiSWLEEjrtoSuiG+6H5YtjKSA3R5kYyTcNgidv+t3w7Ov08a2K1PcLqYCCQ?= =?us-ascii?Q?mEa+HIRt/MV9cQjKYh9XtS09Dff32JvvrwaGKgjVzVLFAbgc+jLmNAlFT/gy?= =?us-ascii?Q?Zb2k/F3MwoytDH18fZhtQNz6yKOiIiivTr5dpW5Zl5TrLLjaCgTjEyf06rhN?= =?us-ascii?Q?yfoJAtl4bRJrNy0UUt+CzJ32pvGCr6TkLZYU9DG6OcrlBhR/NHCS6Txswtu4?= =?us-ascii?Q?/RlzYHXzVdyKHlkXNtzK7EVey7o1o14InygvP0sDVwI3m3jPR+/bofk4G+E2?= =?us-ascii?Q?3EZ/AbXhRDgwrvJA333oByOyEnTU4t+7ZxJKbXWeElpkFVnMnVJyr+kQN9aR?= =?us-ascii?Q?RRZ+0mi3RTkK6rNaeH5Op9uN7AHGEVEnDqh+5L1X5OVkhNrjL0OfBbKNg8I4?= =?us-ascii?Q?UGnweCXA9lEMItG1Pqu0H4hJMeR6pPi39Q2FjaO3XMz7/JP9omw9AbkS4sHN?= =?us-ascii?Q?zAw83XRKabqvumTV4e113hNPYWS/oVqrjJTWEKDh3rYEp0RtgiOELnjVtNGP?= =?us-ascii?Q?atAnzer5FmI8Fnz3PShJobqkyk3QHwEz+4YBHFH7WNGzr7u6BN0BpyHkvE7Q?= =?us-ascii?Q?7kRIA7eV7W8f07USoVI=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR18MB449110939B474D92A4AB77CCD82B2PH0PR18MB4491namp_" MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4491.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 110372d5-9f5b-4f62-f062-08dc426be557 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2024 08:10:35.6075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hhlbTO3h/ZjHMpHDLvFUXFLziqTTEZHrO2yKHqM20TxPmpho3AiFUSM3vrpr0B6HDC56I4F/HC5VgCd/sdSC9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB3993 X-Proofpoint-ORIG-GUID: g7gR1ReKirMOAvyOFxhwLApKzzWIAAkX X-Proofpoint-GUID: g7gR1ReKirMOAvyOFxhwLApKzzWIAAkX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-12_06,2024-03-11_01,2023-05-22_02 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_PH0PR18MB449110939B474D92A4AB77CCD82B2PH0PR18MB4491namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ganapati, Is it not possible to use rte_event_crypto_adapter_enqueue if you want to send the event context to cryptodev? 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. P.S. Please fix your mail client to reply in plain text on mailing list. 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_PH0PR18MB449110939B474D92A4AB77CCD82B2PH0PR18MB4491namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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>

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.

 

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

 

Regards,

Akhil

 

From: Kundapura, Ganapati <ganapati.kund= apura@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.o= ss@gmail.com; Ji, Kai <kai.ji@intel.com>; Power, Ciara <ciara.powe= r@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Jayatheerthan, J= ay <jay.jayatheerthan@intel.com>; Jerin Jacob <jerinjacobk@gmail.c= om>
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_PH0PR18MB449110939B474D92A4AB77CCD82B2PH0PR18MB4491namp_--