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 AAB5CA0C4A; Wed, 7 Jul 2021 11:59:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 754DB406FF; Wed, 7 Jul 2021 11:59:25 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 78D02406B4 for ; Wed, 7 Jul 2021 11:59:24 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10037"; a="207450610" X-IronPort-AV: E=Sophos;i="5.83,331,1616482800"; d="scan'208";a="207450610" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2021 02:59:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,331,1616482800"; d="scan'208";a="627971123" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga005.jf.intel.com with ESMTP; 07 Jul 2021 02:59:21 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 7 Jul 2021 02:59:20 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 7 Jul 2021 02:59:20 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 7 Jul 2021 02:59:20 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Wed, 7 Jul 2021 02:59:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NKpqmf1So94DS3RSeWJY47sIwbq9cx5XIN6h+qLwmk9LwB3OtKuIl3ECGyZjftFf62qB7/qlaC7m6d3NCUgKcNDE6bowFjDosJDaXfZT8Uee4mHUNvRoAEhtdwROyqkQI+nWEXBllZiAdY9AQBNUluAXz3l4ac6GmKRqzLNy8k1he8hEcj0N/25avUmshyl9CWHeKVIcYVxuxYjUZc6P1iZ2mgeQjkZMdOZLT0QTx7h0X3+ACuhvnha6IHMoRoFioviJdTkZ+OYcj/9UfpjJQ+Dc2DRclcLbJMs6bT/S7JDhBmYIHsmY2ma9wSTzO/zNrFIhCemVZ9iNn9KZ7W4MFQ== 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-SenderADCheck; bh=JsQqJpKMpx5QIc7E5JVfAbNVxjgpaWkw2Cza6MrpYkw=; b=Si9657kBFZKLs6RgS3J2XZJDiWO11miu8L4YTgjvQ6oWc6YJsYWudodYdPLYWY+I+8sOXnXn6SwlaKfhxiJ/U9NNpfN3ANehozZJynLc9TDQsN+plL72t8m6VZThG1qJfwEIS/sqaY2u74E20VLyNdA/5qZ4ssz0d5UT6MoHEqcMyAwQR2xRvFj+Hm3Xiadzrky7xHUbwoJrpPk1lbx3sEDztB2BSyRcPEmRK3Nm72TT0LzROLwaavuZj5PvUSxF/RyApCbcgGE2QIMTG7PVc5Y6gy9nVSXgV6/ZfTlaKRZBwcwl615kQz5nolnCb0hhp1qTImw28LIK/+pyrPnWCA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JsQqJpKMpx5QIc7E5JVfAbNVxjgpaWkw2Cza6MrpYkw=; b=iP6wvz20ZUHfHjm8snegBqnuKCqnKNHXqCMGVj7L1/LmFTsK7P7lijmRmtLH80ekgWu7JupTqHcbwD3g8MPNpnS1S5e9OjBThl9nDMbBiNPXTZV/48chL3HEV+0hFhFN8GhJRjFwV9NQCZT96+QFp+fRQxY2xeEDPtexP04l1Sc= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB4475.namprd11.prod.outlook.com (2603:10b6:5:14e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19; Wed, 7 Jul 2021 09:59:10 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48%7]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 09:59:10 +0000 From: "Ananyev, Konstantin" To: Nithin Dabilpuram CC: Akhil Goyal , "dev@dpdk.org" , "hemant.agrawal@nxp.com" , "thomas@monjalon.net" , "g.singh@nxp.com" , "Yigit, Ferruh" , "Zhang, Roy Fan" , "olivier.matz@6wind.com" , "jerinj@marvell.com" Thread-Topic: [dpdk-dev] [PATCH 1/2] security: enforce semantics for Tx inline processing Thread-Index: AQHXaOPPEvFIqFhEn0C8QRoI7a/e16s12L8QgAAaAACAAAK4QIAABe0AgAAQV7CAAUGeAIAACA8A Date: Wed, 7 Jul 2021 09:59:10 +0000 Message-ID: References: <20210624102848.3878788-1-gakhil@marvell.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44116813-f532-46f6-e031-08d9412dde48 x-ms-traffictypediagnostic: DM6PR11MB4475: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1z/6VnOtV7eSAo2NsR1L3SN63P/erU2GGQ36w+yKpsoiDqds6/kk738nfwU9TpVWnTBCquPR2DrJHyJAUf7FiTt9nd/OrpMuXqw/tuk7x0eBkVTKonFIdkM2uYp3jlBqeLcKD+tgVSl9h2Al6FLJcqRn6Q0lJbrCBKOIWCxXTpgyrwfjG/mSsdQbIk1jNMDUdX7enrKgP4go1frkjrXgWp28L2YneKeuSe0scLfIFz61UeDYJTq2eYBdxMOmtcQ+fhnbSeCZ5LM+ahyVEf2mr2LeJIIh5P1+f+P0ukdQvzv1SWff5XLy/KsIIQoVR3DazfBBgcx3EImdG29dpAgWMp/zu5EK7RvR2xxF1Hfwpxrjan5IRcY8Q8+FtGX134fYoJrivbFh5onNnkp1jhufEKlcS1E5HGoV30Coi64kdtbB3Y6i4LxVYRNGhNG53veuAdWnKdPMnfcVFwfp5QyDDrSHYHSk8VvYSM1hcYYbjIKkFz2IEVEP3UFmLV2/ZmKI8jLtMi/tr+BtvSt8peSCrm+x/evpy/4U58bliGjzA8rwreUvyDafGUYjJ8pvDB79R1ZB6HHK5VG9FIuPYUUu2s16IO0HlJo+vA8j9aC8tdlCY3UN4SvxYEg/X1gjP4AkDEKQlNtioMjcTOIQAjvl0g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(376002)(396003)(346002)(136003)(7696005)(55236004)(52536014)(8936002)(186003)(15650500001)(64756008)(122000001)(8676002)(26005)(316002)(6506007)(478600001)(33656002)(54906003)(66946007)(83380400001)(2906002)(71200400001)(4326008)(86362001)(38100700002)(76116006)(5660300002)(66476007)(55016002)(9686003)(6916009)(66556008)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Yh1nf+BPVU++4ZCGc8nsevK7/e7WMT8KUjFO12tD2RtqTCpYGPb8TkIEurDR?= =?us-ascii?Q?CMjvLyjbO/MpEWFAdIEGAdmK3qDBnYDh0WozrqYw3yg9eeKx+uc2fANxF+Sr?= =?us-ascii?Q?5NqCcVTEh9HJJh+OA4RtxtiF/TXa8ujST3qGyfXqv5ZuSwwvirQC2BdlDQB+?= =?us-ascii?Q?RbqWI2izjk8JH2TShR3owxV7V0SMTZ4rjg9brevzqncuQxuwH3VjP+ThTGBm?= =?us-ascii?Q?GXeCM5pHd04YK3UBmKaEhiUDFUOccsS8ZzvGAVGSs92jRIl5j6ehKLGIbAHb?= =?us-ascii?Q?nBL82/2TNzQ159819xPgoMFBFRVA4l4htuJ+NqsdZeI/KsNjGLE7WB7bum9v?= =?us-ascii?Q?r/vR1afvgzlvvs22CAH5H19ML+IAJyPmDeTxjKB0vlt7yaVxw6ziC2mOKOLk?= =?us-ascii?Q?qViJZCjTevD1SPhCiS36z5CymYOxAJNtB3FjoPFabUZmcpssmxYu04th7Z/O?= =?us-ascii?Q?IfWwYSGhe94IzJ2pSH3luUsDm/OzVgHWW7YAinAPJTOFChMHQ/AtMKHh/I9N?= =?us-ascii?Q?6uvHynk09zeysb6H6eEnJ1bZEhgHj6QJZ+E4pds3NZuOeql641KeDdkzwtA4?= =?us-ascii?Q?jwb5syn9iusM4l93LwbcNdhJ3BqYwn91fjpOvtxx1k0AWoI7qD8ttOEQ8eYf?= =?us-ascii?Q?8vvNNZB08qs7DYjDedaBfbJVCYgtaHt8aRUUbcfiylTFW6/B73HYfEesDW4P?= =?us-ascii?Q?VlVhNg9REV8PDOmxQUJ0BOxw9LNpo/uqDFktN6MJHqQJhRcybqlOrcA3xJKI?= =?us-ascii?Q?tpQ4oNb6/6PUIjWrbikpmX6cYDXUzIavv0jCQH91NmPn9M2dtWDrUKnTkkNC?= =?us-ascii?Q?J80VWaAhd6nuftesFZofqYD8NFUUp3Eiq4YAfHFuYOaGiHfsnp50EzSdZDJR?= =?us-ascii?Q?oZpRFwAg98eN/z2ZaGAnfurfrmfM8fV246szb4OhSTvhM7okDgia6NuWOwxI?= =?us-ascii?Q?6VML7pSte9a3mQCYNRCa5ny8CGbgkMSG0WU64Du0fg3zyyILjQCcM0M6kK/b?= =?us-ascii?Q?TCeFrEAaFzUL7J6P4uDA/dw2CQehDuRCws49H6+aEI0f+nny4ALwo8x4Ca8r?= =?us-ascii?Q?bH/3sSE6srqX13ACaCnyBcG9xWEmUDG1FvXvQP5Jg/YgAfu0d9AV85lxTsmu?= =?us-ascii?Q?CICsinKSCURyZFKza1PJmlIFemktdCZnqLEsFyRH04HpqiPaCLnIOS6aLiZl?= =?us-ascii?Q?UFphHpRqkvU0e1nCBEA17QUChk7n4aQdSuPcC/0ilyAbhB3l+XIvWtdRsSfN?= =?us-ascii?Q?mmk2Vi9Ed5Jrh5YnmdB3JgGVRc9NlZLwEuieyp3L/2aArWS6+wVAJLoEdmsx?= =?us-ascii?Q?cxSrwlRB5Zvb2WsRARSZ0IcN?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44116813-f532-46f6-e031-08d9412dde48 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 09:59:10.7118 (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: F3CD4jJUZ7RaAqqxEGlMnoWNBCk9SqSUrWFybWVKbEudOGgAC3fz8NeEYOybh3ZbPKE1qIuo5KLf2vqrYXCrWU99lzdwh+CZGYtcW8zmWtA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4475 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 1/2] security: enforce semantics for Tx inline processing 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 Sender: "dev" > > > > > > > For Tx inline processing, when RTE_SECURITY_TX_OLOAD_NEED_MDA= TA is > > > > > > > set, rte_security_set_pkt_metadata() needs to be called for p= kts > > > > > > > to associate a Security session with a mbuf before submitting > > > > > > > to Ethdev Tx. This is apart from setting PKT_TX_SEC_OFFLOAD i= n > > > > > > > mbuf.ol_flags. rte_security_set_pkt_metadata() is also used t= o > > > > > > > set some opaque metadata in mbuf for PMD's use. > > > > > > > This patch updates documentation that rte_security_set_pkt_me= tadata() > > > > > > > should be called only with mbuf containing Layer 3 and above = data. > > > > > > > This behaviour is consistent with existing PMD's such as ixgb= e. > > > > > > > > > > > > > > On Tx, not all net PMD's/HW can parse packet and identify > > > > > > > L2 header and L3 header locations on Tx. This is inline with = other > > > > > > > Tx offloads requirements such as L3 checksum, L4 checksum off= load, > > > > > > > etc, where mbuf.l2_len, mbuf.l3_len etc, needs to be set for > > > > > > > HW to be able to generate checksum. Since Inline IPSec is als= o > > > > > > > such a Tx offload, some PMD's at least need mbuf.l2_len to be > > > > > > > valid to find L3 header and perform Outbound IPSec processing= . > > > > > > > Hence, this patch updates documentation to enforce setting > > > > > > > mbuf.l2_len while setting PKT_TX_SEC_OFFLOAD in mbuf.ol_flags > > > > > > > for Inline IPSec Crypto / Protocol offload processing to > > > > > > > work on Tx. > > > > > > > > > > > > > > Signed-off-by: Nithin Dabilpuram > > > > > > > Reviewed-by: Akhil Goyal > > > > > > > --- > > > > > > > doc/guides/nics/features.rst | 2 ++ > > > > > > > doc/guides/prog_guide/rte_security.rst | 6 +++++- > > > > > > > lib/mbuf/rte_mbuf_core.h | 2 ++ > > > > > > > 3 files changed, 9 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/f= eatures.rst > > > > > > > index 403c2b03a..414baf14f 100644 > > > > > > > --- a/doc/guides/nics/features.rst > > > > > > > +++ b/doc/guides/nics/features.rst > > > > > > > @@ -430,6 +430,7 @@ of protocol operations. See Security libr= ary and PMD documentation for more deta > > > > > > > > > > > > > > * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads= :DEV_RX_OFFLOAD_SECURITY``, > > > > > > > * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads= :DEV_TX_OFFLOAD_SECURITY``. > > > > > > > +* **[uses] mbuf**: ``mbuf.l2_len``. > > > > > > > * **[implements] rte_security_ops**: ``session_create``, ``s= ession_update``, > > > > > > > ``session_stats_get``, ``session_destroy``, ``set_pkt_meta= data``, ``capabilities_get``. > > > > > > > * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queu= e_offload_capa:DEV_RX_OFFLOAD_SECURITY``, > > > > > > > @@ -451,6 +452,7 @@ protocol operations. See security library= and PMD documentation for more details > > > > > > > > > > > > > > * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads= :DEV_RX_OFFLOAD_SECURITY``, > > > > > > > * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads= :DEV_TX_OFFLOAD_SECURITY``. > > > > > > > +* **[uses] mbuf**: ``mbuf.l2_len``. > > > > > > > * **[implements] rte_security_ops**: ``session_create``, ``s= ession_update``, > > > > > > > ``session_stats_get``, ``session_destroy``, ``set_pkt_meta= data``, ``get_userdata``, > > > > > > > ``capabilities_get``. > > > > > > > diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/gui= des/prog_guide/rte_security.rst > > > > > > > index f72bc8a78..7b68c698d 100644 > > > > > > > --- a/doc/guides/prog_guide/rte_security.rst > > > > > > > +++ b/doc/guides/prog_guide/rte_security.rst > > > > > > > @@ -560,7 +560,11 @@ created by the application is attached t= o the security session by the API > > > > > > > > > > > > > > For Inline Crypto and Inline protocol offload, device specif= ic defined metadata is > > > > > > > updated in the mbuf using ``rte_security_set_pkt_metadata()`= ` if > > > > > > > -``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. > > > > > > > +``RTE_SECURITY_TX_OLOAD_NEED_MDATA`` is set. ``rte_security_= set_pkt_metadata()`` > > > > > > > +should be called on mbuf only with Layer 3 and above data pr= esent and > > > > > > > +``mbuf.data_off`` should be pointing to Layer 3 Header. > > > > > > > > > > > > Hmm... not sure why mbuf.data_off should point to L3 hdr. > > > > > > Who will add L2 hdr to the packet in that case? > > > > > > Or did you mean ``mbuf.data_off + mbuf.l2_len`` here? > > > > > > > > > > That is the semantics I was trying to define. I think below are t= he sequence of > > > > > operations to be done for ipsec processing, > > > > > > > > > > 1. receive_pkt() > > > > > 2. strip_l2_hdr() > > > > > 3. Do policy lookup () > > > > > 4. Call rte_security_set_pkt_metadata() if pkt needs to be encryp= ted with a > > > > > particular SA. Now pkt only has L3 and above data. > > > > > 5. Do route_lookup() > > > > > 6. add_l2hdr() which might be different from stripped l2hdr. > > > > > 7. Send packet out. > > > > > > > > > > The above sequence is what I believe the current poll mode worker= thread in > > > > > ipsec-secgw is following. > > > > > > > > That's just a sample app, it doesn't mean it has to be the only pos= sible way. > > > > > > > > > While in event mode, step 2 and step 6 are missing. > > > > > > > > I think this L2 hdr manipulation is totally optional. > > > > If your rte_security_set_pkt_metadata() implementation really needs= to know L3 hdr offset (not sure why?), > > > Since rte_security_set_pkt_metadata() is PMD specific function ptr ca= ll, we are currently doing some pre-processing > > > here before submitting packet to inline IPSec via rte_eth_tx_burst().= This saves us cycles later in rte_eth_tx_burst(). > > > If we cannot know for sure, the pkt content at the time of rte_securi= ty_set_pkt_metadata() call, then I think > > > having a PMD specific callback is not much of use except for saving S= A priv data to rte_mbuf. > > > > > > > then I suppose we can add a requirement that l2_len has to be set p= roperly before calling rte_security_set_pkt_metadata(). > > > > > > This is also fine with us. > > > > Ok, so to make sure we are on the same page, you propose: > > 1. before calling rte_security_set_pkt_metadata() mbuf.l2_len should be= properly set. > > 2. after rte_security_set_pkt_metadata() and before rte_eth_tx_burst() = packet contents > > at [mbuf.l2_len, mbuf.pkt_len) can't be modified? > Yes. >=20 > > > > Is that correct understanding? > > If yes, I wonder how 2) will correlate with rte_eth_tx_prepare() concep= t? >=20 > Since our PMD doesn't have a prepare function, I missed that but, since > rte_security_set_pkt_metadata() is only used for Inline Crypto/Protocol v= ia > a rte_eth_dev, and both rte_security_set_pkt_metadata() and rte_eth_tx_pr= epare() > are callbacks from same PMD, do you see any issue ? >=20 > The restriction is from user side, data is not supposed to be modified un= less > rte_security_set_pkt_metadata() is called again. Yep, I do have a concern here. Right now it is perfectly valid to do something like that: rte_security_set_pkt_metadata(..., mb, ...); /* can modify contents of the packet */ rte_eth_tx_prepare(..., &mb, 1); rte_eth_tx_burst(..., &mb, 1); With the new restrictions you are proposing it wouldn't be allowed any more= . >=20 > If your question is can't we do the preprocessing in rte_eth_tx_prepare()= for > security, Yes, that was my thought.=20 > my only argument was that since there is already a hit in > rte_security_set_pkt_metadata() to PMD specific callback and > struct rte_security_session is passed as an argument to it, it is more be= nefitial to > do security related pre-processing there. Yes, it would be extra callback call that way. Though tx_prepare() accepts burst of packets, so the overhead of function call will be spread around the whole burst, and I presume shouldn't be too high. > Also rte_eth_tx_prepare() if implemented will be called for both security= and > non-security pkts. Yes, but tx_prepare() can distinguish (by ol_flags and/or other field conte= nts) which modifications are required for the packet.=20 >=20 > > > > > > > > > > > > > > > > This patch is trying to enforce semantics as above so that > > > > > rte_security_set_pkt_metadata() can predict what comes in the pkt= when he is > > > > > called. > > > > > > > > > > I also think above sequence is what Linux kernel stack or other s= tacks follow. > > > > > Does it makes sense ? > > > > > > > > > > > > > > > > > > Once called, > > > > > > > +Layer 3 and above data cannot be modified or moved around un= less > > > > > > > +``rte_security_set_pkt_metadata()`` is called again. > > > > > > > > > > > > > > For inline protocol offloaded ingress traffic, the applicati= on can register a > > > > > > > pointer, ``userdata`` , in the security session. When the pa= cket is received, > > > > > > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_cor= e.h > > > > > > > index bb38d7f58..9d8e3ddc8 100644 > > > > > > > --- a/lib/mbuf/rte_mbuf_core.h > > > > > > > +++ b/lib/mbuf/rte_mbuf_core.h > > > > > > > @@ -228,6 +228,8 @@ extern "C" { > > > > > > > > > > > > > > /** > > > > > > > * Request security offload processing on the TX packet. > > > > > > > + * To use Tx security offload, the user needs to fill l2_len= in mbuf > > > > > > > + * indicating L2 header size and where L3 header starts. > > > > > > > */ > > > > > > > #define PKT_TX_SEC_OFFLOAD (1ULL << 43) > > > > > > > > > > > > > > -- > > > > > > > 2.25.1 > > > > > >