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 5573D45689; Thu, 25 Jul 2024 13:26:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D16B8435E6; Thu, 25 Jul 2024 13:26:26 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 5D35F40DD7 for ; Thu, 25 Jul 2024 13:23:55 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 46ONvpNh022308; Thu, 25 Jul 2024 04:23:54 -0700 Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2175.outbound.protection.outlook.com [104.47.55.175]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 40kbr9stnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2024 04:23:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iAOScJ5PX/PLtJ7mVVuprJ/dZXMi7so1STQl/7Axyxen34iHaM09/eoD9Oh99wszerLIzwHXYbORzsI+QNej+SwMolKqdnglHYWxf9iIxo3uFBXqebEXZLotadEdk1Rn2hAnhnBM0g0d03YYHqtM8fPemjbVbFEbvQkz4jVFfY54OMy/jloeWrA/jsVVX0/M+W2FvfjMzpSxFbPaPt+Nh/+5sZdrAbzEtPz7ofmSdFCDzaorX3SuQFlK9pE3qbQzoG9XjvnQwzpb2q/dY6t91I5ClA2ZhIfTcIjafMbWSnoYUubjYocftkzNdkttjuMrT+PDlWvjqnzzxNTqpXfn2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=JsVB3zhYsDhckXBjeQ8UP6EAtVdO5K+/3c4ysD78raI=; b=T+SAkwnj167skMCPIB9qnV1k9OkX/O/HQ/x8LBBZmmdowHjfkm/2RIm7nytSL/RyaFq1rwINpr0q+sArElx9NEOvdzDEiaFxKM3egh6GrAnK6GiXiWEKU2kU/Rt7/l+l21csx9QGL71FUPahRzk14OhM9ZSCvmV0uRzHKRleQxGmvBZSL/7X7ufl8IIHsXH2TRX7/7dk6B7Ue1V1bMC/jgfo+0t/GODOHA4PSlwxQ4dj5MOaiM2xWn3ALPDo2KLLMaZZ+uKHeivp3dBrSByFJ5hJ63qy2ieBmYLDqiUqea06X/WSwOk4kEtaf7TqFhf1TdtWoyiZ5Y0v+NQ9C1RXIQ== 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=JsVB3zhYsDhckXBjeQ8UP6EAtVdO5K+/3c4ysD78raI=; b=kP0OUELhAcjAJEMIk4dImFImhNr4dYIHRyo3blTiZ/elPzKFDgNtCiZKXyzKQDpv3oS/kzroRqqKSM3zlpw74dPfHffLxqVLg1oXyscMAnEEUxtxpBI5ML5C1GP3VbOairj+FMM3rKQNVyH1qmD3NYFmVAI5mGWX+hr0TbCZ8Nc= Received: from PH0PR18MB4508.namprd18.prod.outlook.com (2603:10b6:510:e6::21) by IA2PR18MB6054.namprd18.prod.outlook.com (2603:10b6:208:4b8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.34; Thu, 25 Jul 2024 11:23:51 +0000 Received: from PH0PR18MB4508.namprd18.prod.outlook.com ([fe80::c4a3:f671:373a:b410]) by PH0PR18MB4508.namprd18.prod.outlook.com ([fe80::c4a3:f671:373a:b410%5]) with mapi id 15.20.7784.020; Thu, 25 Jul 2024 11:23:50 +0000 From: Aakash Sasidharan To: Konstantin Ananyev CC: Akhil Goyal , Jerin Jacob , Anoob Joseph , Vidya Sagar Velumuri , "dev@dpdk.org" , "konstantin.v.ananyev@yandex.ru" , "vladimir.medvedkin@intel.com" , Aakash Sasidharan Subject: RE: [PATCH v2] doc: announce rte_ipsec API changes Thread-Topic: [PATCH v2] doc: announce rte_ipsec API changes Thread-Index: AQHa3QVxWpwnwh/b2kGZlfgTgGNRvLIEef+AgAErwYCAAHiLgIABI/VA Date: Thu, 25 Jul 2024 11:23:50 +0000 Message-ID: References: <20240723130254.2128028-1-asasidharan@marvell.com> <20240723133706.2150828-1-asasidharan@marvell.com> <114420e03fba4aa7a650c2753758d7f6@huawei.com> In-Reply-To: <114420e03fba4aa7a650c2753758d7f6@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR18MB4508:EE_|IA2PR18MB6054:EE_ x-ms-office365-filtering-correlation-id: e0713193-52fd-4571-3e48-08dcac9c424f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?NB4KbHK/mHBjw8JdMDB/cS3ZZXng5Lejvr0BkXYDHEgto4gYHmWOw/ZcBOvc?= =?us-ascii?Q?1EQcZNac8rOJQbUeOj8XlUJSlpFyM8nnyE+oZjWg8LVg9qkenBPT+xfauvOK?= =?us-ascii?Q?T4B9tN0iyvA+gh37dJogdoE/eoePojx1Rlygp9qxz2AiLEcv4ncGE2fpjp6U?= =?us-ascii?Q?bbojoqf/jRLO/dspUxiFdZ4XnL++eExN3hXO3ULHBHkfSq2tbJSTC1fVcJLl?= =?us-ascii?Q?gMoV9X5wayM0ie0ukOrTVr/83K05MjudgVGsCn3ViB+Q8RCgXcbkiBqUtiBj?= =?us-ascii?Q?W5KbTgFJydrpRHeMkL9ZZRmkL4WYy1SZwyrwy5/ZS14XLwoMFb5hwoeMRlgQ?= =?us-ascii?Q?Auxb5YZhrr9W6xHc2514bE/teZRgyc22who7Ry3VH7r0xogmFvOla32s+6bJ?= =?us-ascii?Q?54zabvJcUndlh7lniD1P+mHWD4tTmXl6uHCi91AovoJNREdBPz9RMaH7C447?= =?us-ascii?Q?0UCtOfrVMAEX4AaPH71Y48UCpJ+lNsm+Q+Rq3oJ+oQCGUvep0QB1NQSoARi4?= =?us-ascii?Q?j00lL8sQTnLsouVjw2jD8gI/0BEBMSrbhQ/OVQSWOuASp16Jx0JmAKRxjpLB?= =?us-ascii?Q?xU7Rax4vJvASuOPL1QrET39pAzTJd5nBagQoK2K/1QReXa3KOpfuPRraQF5m?= =?us-ascii?Q?oOr83+4ms30sUdQ61DTe86kGq1pBSY/SUyV8CFP/AUOT7B/TVvJcqm6ta9rG?= =?us-ascii?Q?g1ZJLpio7aywfkiDh/ZeocMPrl1Pb9Ow/CT9OII9IRA2VdYCa1UPtjbjL4WS?= =?us-ascii?Q?z/UgosAskhh0/noqxiuayJuHJ6ZMDmfKvFq3P9+XiJ+uESR2bdD/DdQkxnuM?= =?us-ascii?Q?17g+Ld/6j7KeE8N6KrGJHEeAUsWEZ5l/vzOTIYrKopCsZbdONxRTE2Q43lp0?= =?us-ascii?Q?1xI2J9F5r0mIG6mG4thc26jOa62n2Qpvmf6V/+jUMlRsIP8FPP4d6Gei6d15?= =?us-ascii?Q?V4UnsZUWlsbPYzAIxhG83oUeSfSMPxnMbWZUPDBrrFmNDGtL6TKJH+xWbqLv?= =?us-ascii?Q?KNoJQL11p41ucq8RbiIFKO3eFKz7xYq8mCHvAO8aKQ5Kt6yVyU56KEToHjLm?= =?us-ascii?Q?St1icnFhQfsGlfRz6i9aPb6xarl9YAHX+Yalxyo5CHveJv3eO7pQR39EjML3?= =?us-ascii?Q?CasgbAYVhBWZaorCD8k3g77BYgm2psxcnIXXkF6Jo6GlQugEbYnsdthh25EY?= =?us-ascii?Q?xH9qdpZO07+RpgHCv6QLzp2Nbzg+8g+jzzClhFkDnKvDdFLU6VY8Se0lJyJO?= =?us-ascii?Q?t37Hyw76SLIlDSamGiWZayW8jDMFytMIn7Pn8LwYnCb53BF/drIbXxOeO3wf?= =?us-ascii?Q?8MeL2nkSAcchRr0JSTFr6tKMsNlOB6eNC7fvP/LsVwvHxy8kF0OxrRPc9rG/?= =?us-ascii?Q?8ZFKTshB6lDNOopENWmH/zA9mA7qG8r3rOGfmBV/O/veZImyYQ=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4508.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(38070700018); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HdgRIkGguIRBTfrQbqixsE4+PSCsDaH5IgrALuJN5wmeUN05D8K41iEdi584?= =?us-ascii?Q?p1RwphXRQ+CDTb41LpInc9n0hg92MJf8qUQbB+N9PgICRfwa0InfKOy7pdmF?= =?us-ascii?Q?vJ18N0aDDB1fSgfnHwfcjsuOB8IJe79IYfqy562sHnyP/Iq/MasroKYU9Rx5?= =?us-ascii?Q?5ZwRLNiHNt7UamqRMbpw4G/NAgSFdW1PRnXE5q5XmMZRt8/y+El1+iRfFZhA?= =?us-ascii?Q?QlRL67rBEkrv86A7kxDj26HWlqYAqWK1fjWray4d1k1USL37DSs4KWpN7J21?= =?us-ascii?Q?ikCnQEZdjnqxaz7qVxFLZlokaGRRLVVW1UJbWLbet/kE3yC8/9DmzdrBbEgm?= =?us-ascii?Q?K5igg7Jwm5JyA7Nlwn76+nv5LI2H0eZD4wxahpNcpCJTh8A74k3TMTZYho39?= =?us-ascii?Q?SCiwiXZVe83PB+HaDNR/orfKvJiCnqTzcbMad9xwsdQ+q0+ADRRgLKTKXTID?= =?us-ascii?Q?Z2VNH2z/QPdYG/K9XGK0GAHobHuRJq6MvNgnZEil0yEI80UdPHlI+HUC3eG9?= =?us-ascii?Q?fdYjEPzsPoH9LjSxT/7UDln0JoucFvH5VCMGavHpaAzz6QaCBVqWmiTIxfv1?= =?us-ascii?Q?DotTwptyDboH/tKJKqUenahuFnqETv2BRsZphpAj+N5EsMNJo/lEvP7m6k47?= =?us-ascii?Q?J+SqkYKW1jT8oYnFDz7VCbUfcTE7gMehzVbphX7lFr4l4S5vrN8hsYTk4P9p?= =?us-ascii?Q?t+HY9mZQ2ADwcRPiCrHoZeZTjumnxdwpezJTaYWT+8a57DKeiwmxUJ9566OE?= =?us-ascii?Q?fI7/jjs7NNc9VUKjs65iHnc/GK+4k6ixmnVb5Xoeo3OV6iBGG33DR/OMXCKz?= =?us-ascii?Q?hRYEvNGvsIqA22piO249QGHghEbTTyxWXRPkdEpIfy+0bG2K1/sYOtxwuo4H?= =?us-ascii?Q?+eutGwokiFEJIcNFGfFm+fpv+xpg4U8CNVcYGBcdc5ZQw1Jc0FGq+X8iMxgb?= =?us-ascii?Q?01oA/UL2eaIPbPK5c0c5EZSuEVEo0d7hucVM+6Q1sExmmwV3YgBW01kmqwde?= =?us-ascii?Q?PJK7a6/ehjs0PQaP2Cux1OHbBRxz9n01iiwne7lWHWTDoOIt+JGL2zK6Hxth?= =?us-ascii?Q?gIOADIve6XXR3YFdzc0vxjcuK231hgwrKKGVkYAf3zCmGHibrs38hafp1tpw?= =?us-ascii?Q?E/Cbo2HaawV1mIpFErE6kISYIsLmEjtyildkQwXSZD41/A5F2nmjP7bEmZPP?= =?us-ascii?Q?+ZiNYKfa6c14R1z1FXQcgS1it41/FNZXDeVKnLqk9ZIHzPmcJ0aQwf39SjMR?= =?us-ascii?Q?iucOfrla422N0FiUBbpnJ+jaKFseL3INNtgCJtOqvxGfKo5g5AtifKyABZcf?= =?us-ascii?Q?BiyO1laAX9xhJV8dWLr96JBwaFwmHsFTYzJWE6NUIIb4YwU2H1l6CTSXQDW4?= =?us-ascii?Q?afMZMiAwHtWNiH34xK2QRA2wkTRbNWmQarG0BNWVjsqk1HzO+He+oAn/mJnC?= =?us-ascii?Q?2lp6G395+U1rUqVeyIQO0+R30FoygqzJxkUFmaNT+/I4YU/WIIxSsh/BxeLi?= =?us-ascii?Q?3lIE5qF847+B3TARR6FJsvWVbiyxkiQQZgn/6O+ZPBtIs+GOliREjPsE0Mkh?= =?us-ascii?Q?Va2ngiRIQG7+9hH15vrQq7EEDar4CqOmx7lYpRwy?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4508.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0713193-52fd-4571-3e48-08dcac9c424f X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2024 11:23:50.6657 (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: BiJtRZr3Dl3f+PK5u/Kp7LQXcT1NNSMJIJm2lZ8p59lrvHyYRYvbt9pb9debgCd96Rdb7+e1UVBuYZGHm9RG8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA2PR18MB6054 X-Proofpoint-ORIG-GUID: eE88vgQXzjkrdxr8fKqGXW_uRl2KIiCj X-Proofpoint-GUID: eE88vgQXzjkrdxr8fKqGXW_uRl2KIiCj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-25_11,2024-07-25_02,2024-05-17_01 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 > -----Original Message----- > From: Konstantin Ananyev > Sent: Wednesday, July 24, 2024 10:39 PM > To: Aakash Sasidharan > Cc: Akhil Goyal ; Jerin Jacob ; > Anoob Joseph ; Vidya Sagar Velumuri > ; dev@dpdk.org; konstantin.v.ananyev@yandex.ru; > vladimir.medvedkin@intel.com > Subject: [EXTERNAL] RE: [PATCH v2] doc: announce rte_ipsec API changes >=20 > > > > In case of event mode operations where event device can help in > > > > atomic sequence number increment across cores, sequence number > > > > need to be provided by the application instead of being updated in > > > > rte_ipsec or the PMD. To support this, a new flag > > > > ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` > > > > will be added to disable sequence number update inside IPsec > > > > library and the API rte_ipsec_pkt_crypto_prepare will be extended > > > > to include ``sqn`` as an additional parameter to specify sequence > > > > number to be used for IPsec from the application. > > > > > > Could you probably elaborate a bit more: > > > Why such change is necessary for event-dev mode, what exactly will > > > be affected in librte_ipsec (would it be for outbound mode, or both),= etc. > > > > > > > [Aakash] When using eventdev, it is possible to have multiple cores > > process packets from the same flow at the same time, but still have ord= ering > maintained. > > > > Sequence for IPsec would be like below, 1. Ethdev Rx computes flow > > hash and submits packets to an ORDERED eventdev queue. > > One flow would always hit one event dev queue. > > One eventdev queue can be attached to multiple eventdev ports. > > 2. Lcores receives packets via these eventdev ports. > > Lcores can now process the packets from the same flow in parallel. > > 3. Lcores submit the packets to an ATOMIC queue > > This is needed as IPsec seq no update needs to be done atomically. > > 4. After seq no update, packets are moved to ORDERED queue. > > Lcores can now processes the packets in parallel again. > > 5. During Tx, eventdev ensures packet ordering based on ORDERED queue. > > > > Since lib IPsec takes care of sequence number assignment, complete > > rte_ipsec_pkt_crypto_prepare() routine need to be made as ATOMIC stage. > > But apart from seq no update, rest of the operations can be done in par= allel. >=20 > Thanks for explanation. > Basically you are seeking ability to split rte_ipsec_pkt_crypto_prepare()= for > outbound into two stages: > 1. update sqn > 2. all other preps > To be able to do step #2 in parallel, correct? > My thought always was that step #2 is not that expensive in terms of > performance, and there probably not much point to make it parallel. > But I suppose you measured step#2 overhead on your platform and > concluded that it worth it... >=20 > One concern I have with the way you suggested - now we need to > store/update sa.sqn by some external entity. > Another thing - don't really want to pollute crypto_prepare() API with ne= w > parameters which meaning is a bit obscure and depends on other API calls.= .. >=20 > Wouldn't it be easier and probably more straightforward to just introduce= 2 > new functions here that would represent step #1 and step #2? > Then we can keep crypto_prepare() intact, and user will have a choice: > - either use original crypto_prepare() - nothing needs to be changed > - or instead call these new functions on his own, if he wants to. >=20 [Aakash] As I understand, your suggestion is to introduce a set of two new = APIs by splitting the current logic in crypto_prepare(). This should be oka= y. For this, I believe we would need change in the structure rte_ipsec_sa_pkt_= func to hold the function pointers for the new APIs. Assuming that, introduction of the new flag RTE_IPSEC_SAFLAG_SQN_ASSIGN_DIS= ABLE to disable seq no assignment in lib IPsec is fine, shall I send v3 ann= ouncing changes in ``struct rte_ipsec_sa_pkt_func``? > > In addition, we are also looking at another use case when a set of > > packets from a session can be IPsec processed by rte_security device > > and some packets from the same session would need to be SW processed > with lib IPsec. Here again the sequence number assignment would need to > occur at central place so that sequence number is not repeated. >=20 > Interesting, and how SW/HW SQN will be synchronized in that case? >=20 [Aakash] The design is such that HW would assign sequence number for all ca= ses. HW would then pass this data as a metadata to SW so that it can do SW = processing with the assigned sequence number. > > Initially we are looking at outbound only. But similar kind of use case= would > be applicable for inbound also. > > > > > > > > > > Signed-off-by: Aakash Sasidharan > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > b/doc/guides/rel_notes/deprecation.rst > > > > index 6948641ff6..bc1d93cca7 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -133,6 +133,13 @@ Deprecation Notices > > > > Since these functions are not called directly by the application= , > > > > the API remains unaffected. > > > > > > > > +* ipsec: The rte_ipsec library is updated to support sequence > > > > +number provided > > > > + by application. A new flag > > > > +``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` > > > > +is introduced > > > > + to disable sequence number assignment in lib IPsec. > > > > + The API rte_ipsec_pkt_crypto_prepare is extended to include > > > > +``sqn`` as an > > > > + additional parameter allowing application to specify the > > > > +sequence number to be > > > > + used for the IPsec operation. > > > > + > > > > * pipeline: The pipeline library legacy API (functions rte_pipelin= e_*) > > > > will be deprecated and subsequently removed in DPDK 24.11 releas= e. > > > > Before this, the new pipeline library API (functions > > > > rte_swx_pipeline_*) > > > > -- > > > > 2.25.1 > >