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 3A12D43B78; Tue, 5 Mar 2024 17:47:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C477D40271; Tue, 5 Mar 2024 17:47:58 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 66FD840270 for ; Tue, 5 Mar 2024 17:47:57 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 425DfvID010319; Tue, 5 Mar 2024 08:47:56 -0800 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3wp13s1ner-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Mar 2024 08:47:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0qL0KhEEGJ4eAcpUKte2DiRszmtHALtIAiyjPmKrRLNGrSApAk3VDOGSFEckoj9NkqpyA3C5uNU569b7x85G45sTXoLSBBjFqVb236h1ByhUgDAwyKR5lNFETtngkOEQiwEn86C/ZFOvMVbmGtoRU/uokLwz0SVtfSS15u7Z2OM+J7yRyC01e32zJROB+a7k8L/OJKSqziqYoRG4DTK6/10Wa+ObRCADPKmqt4VGkrEBciDgHu7AVtwPfSqTiRYQUhjmuO+Xd4QRxbJ6+Zfh6OUnHMpGxdrAvAKnQLFv1DS1BWYXUfvodgBzdg9R2QcgGQg3CQ6tAMieNsBCDxWxQ== 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=fbF+5mY+CQI1CVUrc5fT4UCWPOLMCkCFsoxP3u3mVCY=; b=IeMdVvmt63RRqtl9qvteAT8obni6KdpLBVaZZ/aX2utIvQOTunCK5+d+ETSm+clkZTYmgqlgmX6xY6L+q9jyVzXDsEKAycE2Pz2bTKfG5apJAK7Yer+nmtdlMY6LJXYDU9AaJf5HRm7AA/tfFMkjfrpI6iGUl0ROb2HcC+gBUfMNskMCKVvFEJdo6AvGtOB9eGHCl5I23eXjDuLxMQufZAjF77N7y1i8xL8ej3FxdE6knPQjrxx4+f/ElA7m9iYXOO4iXvTYYuzy0FiuGjOD24XoPceN5XLNJELtxnjkOft9gntWfBQTVjufaNwP8KBdQyWUtAARi9uOuEA+2TfA6g== 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=fbF+5mY+CQI1CVUrc5fT4UCWPOLMCkCFsoxP3u3mVCY=; b=UW4jCwpqAGp4/c4ixXGco2ueSSo9IzI9Rr+VpeAbiTmvIRySyaX4kp4u4oZXMAzyLyqph2MwRR3zUKRINYhKqurIoPamGT9hNT39rz3gVYakWw7q8C/M9gdYH0zLKmzy07VcbkknIk6x8du4GZEOrqdg52kaWJgoVfiKrwmoRcI= Received: from CO6PR18MB4484.namprd18.prod.outlook.com (2603:10b6:5:359::9) by DM4PR18MB4223.namprd18.prod.outlook.com (2603:10b6:5:392::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Tue, 5 Mar 2024 16:47:49 +0000 Received: from CO6PR18MB4484.namprd18.prod.outlook.com ([fe80::9345:cddf:24ca:5be9]) by CO6PR18MB4484.namprd18.prod.outlook.com ([fe80::9345:cddf:24ca:5be9%5]) with mapi id 15.20.7339.035; Tue, 5 Mar 2024 16:47:49 +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+MAvLpaLTkGIacnPGT5mjgAUF2vw Date: Tue, 5 Mar 2024 16:47:48 +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: CO6PR18MB4484:EE_|DM4PR18MB4223:EE_ x-ms-office365-filtering-correlation-id: ce0cd474-fbcb-4256-36d5-08dc3d33fdcb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TaiI8GphSZw2j5A+xXz/iFXAwOIMHP8pcp3s3Uuhu6x1BjzIhw/YP2OfxQytj7hdK4QL7oWBMo9GOoybioA0OmUsKIe5PT16/KfQY4K6JhFJcRjAH+yHmjv29c8g+T5EdINUgsaPwvJtj5qHqohVRz4o+rSsHKjeCyHUEdqHy3N2LgLaVJtByoado6iR+VepPB0QT5VD3lkN2pbfnWkdfp3ARpgOa0cEsuLTlVfGEvyjGyQsG7uIQyoyj5MB+9PUv893yKEpfV6YdPokBdjT9dmKIGWPmLN7tqtVbEHTc+RencFCmcssrjEygmJagCdxbjaJcQqknx6YqLZ281n14NPtcJ5ThQ1BJ2gXXgcejDxedzoOYIJ50xiTHxIAGuzEbVrsVToredoNE8qAQeuRK+Xdd9sciByK6pYDtF8NHzD8YCcCR56HXfWVqwdQmsvbBeAk2Y+94o1ND5NLzayK0Ea7nfbaPZvre2BO+QuB2ep5x4JuxvLtBqdRXVGJXHO71Gyk4NyIrJad+bc6o7SG3R9iQQhyBRv7O+yAjDA0bogikuq3hg+5hbSKkXGvYltfkkkLD2mUuOwW0Yuf7HNC1kK45eCOawQev/V3BMXTGFFL2Pr54pCtSY5q4GXUiuBwzanTAnwNLKrsfxPhNWlzU6/QGLIc0DVdZsWApqOUd70JVdltkRXQ5ODrNwcGMYbWnvM/fpeQleNiAjHcok7EaiN76ONxMWWGE3V08HtN1IU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR18MB4484.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(38070700009)(921011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5kriLLPT3i/KxCpFzpPFaoaeMxIhHOB4iI6d/YUV7GrUIPaKlzC5rH/+y1b7?= =?us-ascii?Q?5Rs0Ulsi2MLJoatD5yjOhbUC+n1zVWF2Jj0t2lhARidT0etUYAqOBRQyiBs0?= =?us-ascii?Q?0fRDsuqh/oWgFqFs0dUlvsYxcngZhe0JEVQVJlFbnT2IVsCmPrj07Bdcd0Xp?= =?us-ascii?Q?4e6ONXHPFJSlrDzCE/xMZ0v2wVQq8K988vNvzeqsIHBbkJXe1W9nUsktAnkV?= =?us-ascii?Q?zLVmCHMlR9OyuS3dE4HWPZutm6ajl239YfZskohdnmpKytHoq9CU8OVpxXxc?= =?us-ascii?Q?qZCux1vKWYDIZEqLvtpc/ov3VNuA71uhSQrbK9sU1s8hvPboDeI4/yg21uw+?= =?us-ascii?Q?njpmdX2juTRqEe9K8Pq5kwtF7DlVXbKNyRlM2XCzYTc+Fob9Zd3JinlAP6Of?= =?us-ascii?Q?9xO+qNUP+X8IXRgvSKMc2owSVv+6eC0P81s+FoMdY04iHyndoIm5IOLhdvDc?= =?us-ascii?Q?uULN1dg27GNUyg1I0ve4G5PDFsv8X3g8nAsaO+rn8jGCBrBxB+6FoYdxOzXm?= =?us-ascii?Q?YvjRjtIqDtrFl+C0OwG5BAyTxMBV9J0PLt2dltbzj2ccWtkL5hChrM8TxXDw?= =?us-ascii?Q?iMdMWxjPqwjASNzweQfsakzlfD5A1BnTkLDhzsle4SfKXSIKjd1ep79pcwIH?= =?us-ascii?Q?sfauabsQ8rrc0by42M1aJtRV4+gxfzuHHWNfwRq+nrPG1IUubNuVn6JCX+tX?= =?us-ascii?Q?nAScs36lzV2McPQLvwWo/sj7SUSsHASKssKVZmy4nlXl8a+sqBqocRoTRAZZ?= =?us-ascii?Q?+Gr8S/yZ77GAD6biGUS70sv/L7UOPbOaHh/6iQFLYklwUW4OPQuP520d00y/?= =?us-ascii?Q?KSkwIrFdHHGdPZ+u2gIIg8InPMWvrQ7MLp4wr88rau1c2G+H0RUnB66yAnXQ?= =?us-ascii?Q?kP32PSiwJpzBhDmi8fAb5buIzYQv8tbbmbsxDmTYcOj0Ch94mU1B6mSEeLKa?= =?us-ascii?Q?Mq4b9CL+p36vzqcjkh2TL6/RFeKCHL0quKBqBX7zaf8Hb7zr/LiHmOxQJ8oa?= =?us-ascii?Q?fsNmXdyMC4kF9j6OUbgp7ZoVwUnAReh1xShkVR+2STgddX+KsEifmoqIP4Su?= =?us-ascii?Q?LyDePNbVw1WGsQKR4cM+vdam8O7yKI+sXog9oezmt/DEgwtTzlhAL19niiK6?= =?us-ascii?Q?1y8Gj+Cmy61GPPJSBpjtoTJUZLBvqysieReWaGS3DZBHismIg1P3zBYS6C5I?= =?us-ascii?Q?28EhpPu4hfzwlBpkPY7hqdpEkKxQDPjiS/03cSB7B+mjw4Yd5uJbpmCp9Vcm?= =?us-ascii?Q?SAy165boe38Ce/y2lfHGgkUIg1dXaD3XaWZQG00KraN6prQreU1X5r0xoL8d?= =?us-ascii?Q?d083BeX27CY45XOVXlkfas0idFO9lUi+pNHP89Ab52MbpZ7rxZLjSqMZuFTZ?= =?us-ascii?Q?RvcoWurw2LrSq9Ivqp26izJBYkenVk9t+0LuCP5rm6VY56MqXsnD+arHP5NP?= =?us-ascii?Q?v+ekgYz/xlA6NvsIT5QmFdZXU4scP1uMgKaV8P3/ULu+RVipUe3NTwN6wDzB?= =?us-ascii?Q?M8C2W2JLYCpimHD/ECrabDUuKHAsw2yRxp2lBU3KZamOMBzWxIVWKZRhM32B?= =?us-ascii?Q?CryadTJZ2BvJO5aoIB5WTfPotscVEheq51mqzmBm?= Content-Type: multipart/alternative; boundary="_000_CO6PR18MB44848FE7DF0D4BD135417A7CD8222CO6PR18MB4484namp_" MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR18MB4484.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce0cd474-fbcb-4256-36d5-08dc3d33fdcb X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2024 16:47:48.9860 (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: N4nEEdSJgUAmRuMf4NCKNiDDksStS2+g6TkK0pBNzKQFmFUJCq9dyLuac8IigcoWFYzGUJA/zpq6+aJnCCzD8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR18MB4223 X-Proofpoint-GUID: DNFe7UBV_fwdhElnnMSxkL4BcGdSqwDB X-Proofpoint-ORIG-GUID: DNFe7UBV_fwdhElnnMSxkL4BcGdSqwDB 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-05_13,2024-03-05_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_CO6PR18MB44848FE7DF0D4BD135417A7CD8222CO6PR18MB4484namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, ArkadiuszX ; 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_CO6PR18MB44848FE7DF0D4BD135417A7CD8222CO6PR18MB4484namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ganapati,

 

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

 

Regards,

Akhil

 

From: Kundapura, Ganapati <ganapati.kund= apura@intel.com>
Sent: Tuesday, March 5, 2024 12:44 PM
To: dpdk-dev <dev@dpdk.org>; Akhil Goyal <gakhil@marvell.co= m>; 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: [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_CO6PR18MB44848FE7DF0D4BD135417A7CD8222CO6PR18MB4484namp_--