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 98CEF456E1; Mon, 29 Jul 2024 11:54:48 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4DD70402A2; Mon, 29 Jul 2024 11:54:48 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 1E24340261 for ; Mon, 29 Jul 2024 11:54:45 +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 46T9CMeZ013069; Mon, 29 Jul 2024 02:54:45 -0700 Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 40n0dqmt6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jul 2024 02:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D7SjWRJ5kVzEP8NXMDxBP1r57RG8usWJIW0MALauf9+doZVt7Q3bgMoyWTuRu8pDIsxN48cONwOL78MygRTBlu7jmGh2kmK2Xl4Bc8Mj18nnOqrWNr9pIuCgEIppLouuqwcumhgwZ6zTsFpatUKs2amENDDn3PW+xKerphpro1MeL00Dyp0dYXD/ukfcdINXWwcRggXvqVHM2uWut2NOqRKf/Xj2cqDiUUgPFHnWaYz/lDs0avQ+v1psRgmCR89+YRWyYEExWErp2llbYUo3/FUn3fY0kWaMgZ+xWWwwFquQ2vurpZrMeCL0OGeIZjdtxCoQdzqUmHO6c+RX3ttyEg== 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=xDIFwD1Ax8mUWPv9JXNIHctrUcyDJ22RBkqR3H9GvAI=; b=CnbOg2Nahq6Pxv+jz2CBXl1s5RQrt7oUrhQ1p4m0pRsQgJ71BTK9nAsj+taphZTvvUgCMZYmDnVJWd+DHdEPX3GjbsBAfAwNUOgOcTbwLrgFxmea+Z5i/TtadPV3N/v9s790Yq0pbc6RwnTawMvxmuT/S9PnVU/PmMwgDRQjcnvXjsJHJ/b4t1IWs2i+az371z/S+G3X2sVZAwZn183NYbcWLH8e/25sQC2C3388pztDTduvaG6hyV0s7/hMc9HlVzCUE3zJxXDrFM6c9c7F52h+edUHf8eObdKAPzKHYyl98WkOP8DILhjH1RJOYjEYp0xRJhjjfA2ePi70JBgJUA== 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=xDIFwD1Ax8mUWPv9JXNIHctrUcyDJ22RBkqR3H9GvAI=; b=Ua77mKa0p0xhIEHI44peZoEPRZ6WJGl+2dKHU9jbf30Q0tO8+n1hhmAnvyMWsFwa6K4z5tNQHAleIryPB8LRzAZ8x+kz3n0f4l2FcyBfUnkcwDdnxTUvKDoWPNNG78eMea3lTAqeKgKrJA0MdTNzv5gbOmmDj4b3ltREf3tIg+o= Received: from PH0PR18MB4508.namprd18.prod.outlook.com (2603:10b6:510:e6::21) by SJ0PR18MB3962.namprd18.prod.outlook.com (2603:10b6:a03:2e1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7807.27; Mon, 29 Jul 2024 09:54:42 +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.7807.026; Mon, 29 Jul 2024 09:54:42 +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/VAgABY/oCABaA+sA== Date: Mon, 29 Jul 2024 09:54:42 +0000 Message-ID: References: <20240723130254.2128028-1-asasidharan@marvell.com> <20240723133706.2150828-1-asasidharan@marvell.com> <114420e03fba4aa7a650c2753758d7f6@huawei.com> <507435567e654c3382f0f425bb02a71f@huawei.com> In-Reply-To: <507435567e654c3382f0f425bb02a71f@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_|SJ0PR18MB3962:EE_ x-ms-office365-filtering-correlation-id: 8b8fe87f-9bcc-4240-0a16-08dcafb47815 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?M8CE/jr8St5tk5qLoaJspFbGFkvMsIAik2JqFWuYe/DxIHBT9zpWV+EZBqfB?= =?us-ascii?Q?na2aH07Zqk3MSUqpGYQrbWfj6HiBpgCWTZYHGhDhNaF5iOV4ZAi83w6dep5V?= =?us-ascii?Q?Fsmu44dzDf1Hgtak/+nzp1deJsL8x1QIjUv15n+RCDI36n18eSpxe3qySAdY?= =?us-ascii?Q?VgPzATGfVpgcLeMmfdhthRyv47N+eFFjWXwf+uCo4RnFWXBWchKp/Nb04oEw?= =?us-ascii?Q?f/6Pkks0f9La3hUJoUdH/dt1SH62ypwsFGuzYOyXcJe9k2Yx9I65Iuw98Yti?= =?us-ascii?Q?MhbeQG7wR5I9G2JuT8K9GuKMQWdgudG34eL6ircB1Z/BitBBaXPIYLvpeBul?= =?us-ascii?Q?xY3TnLvvy00QKOhrDqjprxc9OMuFMPUUMRmG+gY7o8fu0mL9FzzUS49Iy/oG?= =?us-ascii?Q?eOOIpjMuXMIZ9UoJXEHbcAzaI3rh3Ys1Nu2hmftESbi3caCauNltRr7edpTr?= =?us-ascii?Q?3xPNbJtYNJrP9xgMZJWp7sibDtki6eDAtAF5GzWuwO/nxElOplfO83bnz4WX?= =?us-ascii?Q?os+ij0eImSHq+g3SsVUn1HkapnPBhWggHmMLiHpIg7mJWp9oNsqqs3+C2tlw?= =?us-ascii?Q?1Tvq9OJG/Ln7NY+2adiAIyqk8nDaAit06j/QO1RoBCL1UjtknB/AVE3q1kf3?= =?us-ascii?Q?aqmjpUbFn6kwvJsmCvGposZKEez/fCo1/QkTD3NLrz+YwG1oGVolzQuC6qhj?= =?us-ascii?Q?9hER3Ik/WyZbc7azcWvWHThK4Rbc14op9zWm1S/oIXFVW7+2RnMxeHl4K2cV?= =?us-ascii?Q?Ujt+ivVybd+hdB8+fxlg65H8LhdyvK8Nx5YNeLhan6E5cpf3ULeuiBVQrcR7?= =?us-ascii?Q?KbtUCJsX9pJfNNz/BEPRKCEaqjqV2P7KIRSjD8McxbiH1NHjwdj0glTu3TCY?= =?us-ascii?Q?JA/J7j1SWmVhDf9puVYIJD8aiW864AxOIwWOyIch6ketFyqri4t21832/+Ik?= =?us-ascii?Q?Fe9E6Mn6DPUL7AytNV3HYo7eT9HoQgweqA9RhDWoZr9rYaQUFkYUcP6QZ9Wl?= =?us-ascii?Q?cQGIDcQntnWtVFVIfxzBfQzzywrHK//y2In3LuWC/qOp5y3/9h33P7vsuUPz?= =?us-ascii?Q?4Ob6h1y2C3nq+NSRcFKRWj1OWQF4WJ5YaXXeo5zgi5rn6u5XCl3G3zkDYa0r?= =?us-ascii?Q?2td7IiIzAWuiOzZ/wFjmVFD8PflA1yVDytByR2NYsrZ++viAsIX1YxSDxAYU?= =?us-ascii?Q?XR7cyOSEO4shjYIoFLqgFtb2JuUhoKqjvUDJQlpOyVpjLSRasXGDz1i8lZ2E?= =?us-ascii?Q?b6Z70EWDX80pXUgZ7vfKyTuVy5c/D46F5i7JalazBuiY6P6wsPiQu/qLZ27F?= =?us-ascii?Q?Sr1jf8CFMYeVgnK3kfSi5eNWQBgM0U3NpIkFyBtwZrsugQz/nnyNCbmoksXs?= =?us-ascii?Q?JgzTfvTvHpAvKomEbPF0SZtll4KxZxm+/2Y6PoW10oXJnvkOOA=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)(376014)(366016)(1800799024)(38070700018); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ul4OS/I5a+5vY41cjQ6cfgSiapiUBKAnccWd0AgQZEKpTGHf3Qh7YcGtM3MM?= =?us-ascii?Q?lW4QSkt7I642KF1oxnrCsIyFvNBPbmif0ADjnzC1i2ABxE54nOZ/TDkvCXMR?= =?us-ascii?Q?6iY6ADO7TafBY+ms2Z5XLdio0n1Dzohjc6BASsVgYxjqWBc77cSlzTF+4LDu?= =?us-ascii?Q?maeD6u1zje6vDxYsQ3isZrsglpAib/Nqb+sQaBx0GwKTL/gZuLtc1lg+kMsr?= =?us-ascii?Q?QIubst7gz0GkdtHCvZH8pDnRgivNy+SCWNNWrau59mRocbS0tAJtii+V937N?= =?us-ascii?Q?4B3gWslbUK5Wm9s+MSrqBAFw4AcR/QDY8zYqjOnhn0sJCahAbniFjoqY1zt6?= =?us-ascii?Q?Z9JIsh1DqLci5zwe/fYu0GhDAHKcyxHHVPeMEzUpSbwaHskM7zbjwKaUMccX?= =?us-ascii?Q?YfoFoYniLoq3RtebsI+DrNzXdn+qMqMNLJRdMjMx7KjdZWhKzZs2002+eBfB?= =?us-ascii?Q?lsVg2jJqOrAeS7fx4ZVvMCFIG32wU65YJHWwA1Wb7s2X0DRuZS+pP1Z2wubw?= =?us-ascii?Q?8KCjhmOCfj8dwRTO3K4bIUOb8QLTc0p1jA6lbcZ8HJ8DSVAh5OF3eXs5fd2G?= =?us-ascii?Q?gKKGjF5gIIROSN4+KhfdvrnCAtARAAZFLf4xAz1UYQKqtaPzX1D00IH+QEIX?= =?us-ascii?Q?2PUjOy50wRunkmBzkTolsmHyHU9biSePSJT3962mrC9FzROjIYD3X26APJcc?= =?us-ascii?Q?Gqw0vTjGn3UXRJoAKqAqdyqRW4QzasD7YkFkP1Jc/wUqIFC8WWBovO+yUaAm?= =?us-ascii?Q?d4T4xqy1GF1FTuG6wn3O/l9JfG8p3QAxPhsMpCZRZ7vu+DjEhPqnMj9iqbHT?= =?us-ascii?Q?1LcjlVxv+VaKFyO01QmfT0KepwGPH5rP2H0duG6T9isM9g3MkVGTxEOHCRNJ?= =?us-ascii?Q?+aLEsKPgMGnPULGawBcs6q5hIuYyzoldKrpkNUPk25qqcALlr2fjrbT0Ive7?= =?us-ascii?Q?cdymsgv5gWIJ0aACFsWN0kkG0Uad37OE8Q/9DgnRLwJCKQpTMklvF2WRNQpQ?= =?us-ascii?Q?v3ytpVEBlYVHIMnzR+kY0UlQtqOybIDSMiowcQR/Corq3++a/Piwi0m/Aakc?= =?us-ascii?Q?ToGnHtHACK6WQRzelJz1osrlDUtfEtgDmGxVzYXJ6Bv8ixJFdvQQKY5NrIAM?= =?us-ascii?Q?ngeP42ERvV9afIuui0/IcKfLF+jhLNd/dXnfuhn8oLwPqMpSXZnSSJuBcG+u?= =?us-ascii?Q?6OaOdqoQ2t9/1qPm6rLUtHth6ssKQkHNxT2O+vrx115P1ELLOM0YuzFgKJPY?= =?us-ascii?Q?fyKw8lqLQeTsp9silMDQCzaAsmrXjHcMTXcdVAdAG0+i6Bp3OmyrWqIqwbnm?= =?us-ascii?Q?QE3FdQ2SoO9e7BK4CGotEPf8n4I+zUCVJrGxqTBfXXx1YfX51+jV9jMfcLwB?= =?us-ascii?Q?692N18Xd7i16XFp9bGSJb+mnq6uGvKeoAAcFCj7FytN8qbsYIB1GAXcg/ACk?= =?us-ascii?Q?mOUVdPVNArH8vdobbSEgIvH8JjX4ZZ/JnbPKSmZ01uB5LsRObqil2LrHYsxL?= =?us-ascii?Q?w6nFbNZc2CAnhLb0BM9zVjttYrnyeU2qQOT2KaqIXPUQaD2Z69aDENaksTbC?= =?us-ascii?Q?fp0kvVYtoozL2k7vekPMwW8EFrK14u3DKrsdG7ka?= 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: 8b8fe87f-9bcc-4240-0a16-08dcafb47815 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2024 09:54:42.2847 (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: Syrvb+rvA2ou5/EDGnt4jSkLYhSu4xlQwK2QxsVWHvacviFnB3Jrp1Z0Zr/VhjViO7D8sOAlAgdrXbGtEEAT3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB3962 X-Proofpoint-GUID: hvWylzbF83YTc63MDKzwUP2vJo9SbdhA X-Proofpoint-ORIG-GUID: hvWylzbF83YTc63MDKzwUP2vJo9SbdhA 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-29_08,2024-07-26_01,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 > > > > > > 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 applicati= on. > > > > > > > > > > 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 ordering > > > 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 parall= el. > > > > 3. Lcores submit the packets to an ATOMIC queue > > > > This is needed as IPsec seq no update needs to be done atomical= ly. > > > > 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 > parallel. > > > > > > 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... > > > > > > 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 new parameters which meaning is a bit obscure and depends on oth= er > API calls... > > > > > > 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. > > > > > > > [Aakash] As I understand, your suggestion is to introduce a set of two > > new APIs by splitting the current logic in crypto_prepare(). This shoul= d be > okay. > > 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. >=20 > Yes, that was my thought. >=20 > > > > Assuming that, introduction of the new flag > > RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE to disable seq no assignment in > lib IPsec is fine, shall I send v3 announcing changes in ``struct > rte_ipsec_sa_pkt_func``? >=20 > I am definitely not against this new flag, but if we'll have 2 new functi= ons > instead, do you still need it? >=20 > > > > 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. > > > > > > Interesting, and how SW/HW SQN will be synchronized in that case? > > > > > > > [Aakash] The design is such that HW would assign sequence number for > > all cases. HW would then pass this data as a metadata to SW so that it = can do > SW processing with the assigned sequence number. >=20 > As I can see there are two options to fulfill that requirement: >=20 > 1. Introduce a new function that would update sa.sqn value. > Something like rte_ipsec_sa_update_sqn(...). > So when metadata from HW arrives, SW can call it and sync sa.sqn with new > HW value, and then continue with conventional rte_ipsec_crypto_prepare(..= .); >=20 [Aakash] With option 1, one issue that I can see is that, multiple cores ca= n call rte_ipsec_sa_update_sqn() creating a race condition. > 2. Introduce new (extended) variants of ipsec_crypto_prepare/process that > would take SQN (might be something else ?) as extra parameter, something > like: >=20 > rte_ipcec_xprepare(const struct rte_ipsec_session *ss, struct rte_mbuf *m= b[], > struct rte_crypto_op *cop[], uint16_t num, /* extra params will b= e > there*/); >=20 > Which one is better, hard to say for me off-hand... > Might be both are needed. > But probably we don't need to decide right now? > For me it would be enough if you'll outline the plan to change and extend= ipsec > lib > API with new data-path functions and probably new flag for session create= . >=20 [Aakash] Will go ahead with the option of introducing two new APIs: 1. rte_ipsec_pkt_crypto_seq_no_assign 2. rte_ipsec_pkt_crypto_xprepare along with the config structure changes and the new flag for session create= . I will update v3 of the announcement with this. > > > > 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 applica= tion, > > > > > > 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_pip= eline_*) > > > > > > will be deprecated and subsequently removed in DPDK 24.11 > release. > > > > > > Before this, the new pipeline library API (functions > > > > > > rte_swx_pipeline_*) > > > > > > -- > > > > > > 2.25.1 > > > > > >