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 4ADBDA0C4B; Wed, 14 Jul 2021 13:09:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21A47410F6; Wed, 14 Jul 2021 13:09:19 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id DC99740E3C for ; Wed, 14 Jul 2021 13:09:16 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10044"; a="208511241" X-IronPort-AV: E=Sophos;i="5.84,239,1620716400"; d="scan'208";a="208511241" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2021 04:09:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,239,1620716400"; d="scan'208";a="494148591" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga001.jf.intel.com with ESMTP; 14 Jul 2021 04:09:11 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 14 Jul 2021 04:09:10 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 14 Jul 2021 04:09:10 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx603.amr.corp.intel.com (10.18.126.83) 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, 14 Jul 2021 04:09:09 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.176) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 14 Jul 2021 04:09:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SNNiF8WdUHaozovcYhGuBZuoytfaxpOwN5zma1OdRljCeTKPvS2GxxvT6vuEPGvIyZN2rGErBF/uJgoNpZJTk8Mz7r/mBeDjYzf5CuPEmaEN00ECZYLl2IlhlRUiGZ31o9B/vSZoS1Z7Tp6EAnZhAbbZk+LpS7561FS3u0EGFi1RpgdhRta3dC5YBFzKqjwAfXzJhANb7qU5DlLMjHpkC35iLPqUIQqai5AW4ax1GXzMP1igIEU7X3JO3N5ykcKIwfnfP2oQHi214GIO4L/vYrtK0k7CkOYzSGzZ5TPkZRP/QBlRywDas3ZpYu3X3rmFpT5lU38qVNoI/fwwZTpz7w== 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=lZ8Fu6M9hfh4ixFiNLXWR9Qx+BmEWG4Tf36n3FaGbco=; b=jHosINw1WxFom8mBpYa65WZrRm2s/rqmIv2h8+u3+tMKqHYV3sDzfQb1KMNH2dWIPafA2k3mjkx2KiR9ZjRCKn4ZrA4kOA4fW11m+96e++d0iXLkv8pTazpLX1CiaoJjkdxYATEHREfeIAxYtFI6gWOWt50+Id0L4lUoAwS1Yjp10tWm7wfHsebOXP/UjSs0+e9hU3C6gVqYX7PSkGNEVQszKCogOVYJoyuLX+sHbpU0hLPnqYm88NkL8whas+BTCWmtjiKn9p/kP2KITMTbazydnn4+QFbzTUfKmoPYAlniRE2CtJR5gB4Mx6wP2OI0O+0GehIcl+Szed1ppyw1CQ== 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=lZ8Fu6M9hfh4ixFiNLXWR9Qx+BmEWG4Tf36n3FaGbco=; b=FsLADD0PhntXXWrzFFdsuRiCwkVpme/kqlpXsGuMiXQsj/VhhJ10s9wUZAQDuLR1ucfI/wvtXyX4MRAHyIoySFRIYlruxWV1p7kmHuTG8s7k1r/Ls2SoMnCygK4PrZXD8CtIOQgHpX366L9bLkKvjKFm51aEzI8xBefPGyIPjSc= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB4740.namprd11.prod.outlook.com (2603:10b6:5:2ad::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Wed, 14 Jul 2021 11:09:08 +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.4308.027; Wed, 14 Jul 2021 11:09:08 +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" , "Doherty, Declan" , "Nicolau, Radu" , "jiawenwu@trustnetic.com" , "jianwang@trustnetic.com" Thread-Topic: [dpdk-dev] [PATCH 1/2] security: enforce semantics for Tx inline processing Thread-Index: AQHXaOPPEvFIqFhEn0C8QRoI7a/e16s12L8QgAAaAACAAAK4QIAABe0AgAAQV7CAAUGeAIAACA8AgAAdpACABMZzgIADc9iAgAEZGjCAAEfdUIAAH6CAgAE9COA= Date: Wed, 14 Jul 2021 11:09:08 +0000 Message-ID: References: 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: 3c954709-6d49-4564-9769-08d946b7cd17 x-ms-traffictypediagnostic: DM6PR11MB4740: 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: elpE5h1GsgSDbRSRDGkLcInG/hEihP71OdcPumRpAe9qZhnmK9t3b79bPFGuTJS0rBbFrFuBY3wRO34WcpeVjJhqUi63vrnp872kBmKo+slRhxdKKwII1nBdADVklzsLCZ7susWh5J91GIRmaAVKiqF+Q4UVMGTLjQ7vxfmGeWZWf+9MkENGvRx8XOEA34yaBZXVnytkT2IwDvyCzS7RzwocrFiwiKDTcfFnM5aaFpytFAYPQyTad81AIvjuLD5Um7qYxdNjCHxuPrUyUILTDQYqLxAQDQunWB5fQxfWK7zeUtMjVsNpD2u8Wr3jaraXs8neMqS6Af0bOVo681HVgD1Z5dCQ8AL7x3A6VJV8pOjstRqgmIboG3CbdGrOxlqDYvUawnYdnvSIwn9uWq4SxEeXWNDjqcavd23R33ICpiPOMbeS556hiZRzDFQqbIA/gaqwknRYxNRcX/NFnXFia/cxEgshGcEtQiCn98MzNnRmC+zMN7nyf8BVkKGRUGOHfNll1P3aM5KKt4oY2TH7HlgRc4wPmFP8hpfXDrHc9qGXuUr09J+HiA9OCwwjcrAI/yKk+7w5S2WFhSEZKMtOkpfSCHd78K8N1iRpdpi4Xehr3dhdYFoX4RVUyOiai7CZQOVmCgtPKpv+nwU8yUmWvXpx7uvA4uud7ypMz+XgMtnD+FCOdpKz3rOHy1sBhrZGprvuCTxYPdmpTosgpGN/MA== 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:(4636009)(376002)(39860400002)(136003)(396003)(366004)(346002)(8936002)(66476007)(6916009)(186003)(316002)(6506007)(38100700002)(86362001)(4326008)(30864003)(71200400001)(26005)(33656002)(8676002)(54906003)(64756008)(55236004)(9686003)(478600001)(55016002)(66446008)(2906002)(66946007)(5660300002)(15650500001)(76116006)(122000001)(7696005)(66556008)(7416002)(83380400001)(52536014)(38070700004)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fS8JTIytAJvL0SaiDctmDbE0obpJfvw5t2S9B6CoJoeK7jlMgRjFnxxJj+v4?= =?us-ascii?Q?x0HQOL5ms3SgGlzJRnJh8SajaN1qfVEYGOC5A0FegXhiG1/xSRQlRcK/okT4?= =?us-ascii?Q?7fwie1MBd1ZBUg6dP8vPTvLhq6NH4G0Ke54HfMGnsCx3FOUR4O5Axp1AYWBQ?= =?us-ascii?Q?yfGivDl8zmonRiscuz01benxoV8o40xH7Q9+BWI9wES/Lc9ufGQ3IYViT2VK?= =?us-ascii?Q?1dmYYb+uPDkee5ezHuWp4eChiLIh/7m+6n6gDdiYNwzHPMTKTNPNGNDitG1v?= =?us-ascii?Q?rqg60Qm2UC+00X9Em4lMvGrw8dS/1dTeyUNRlAtBolQzxwOuUAfvTzHqKf9P?= =?us-ascii?Q?B3yudTOU/bBdZd+bfL17fXcUKFdTIk2TkzuvDt2Sv97njjXYF9/6r+qi2lt+?= =?us-ascii?Q?4/8pZ4s4HSXwWmRGTXgcMpU7m2XHAwTp8FZHEiJYuHRdk0sLxbMpkOAE4ZNg?= =?us-ascii?Q?0B6er5CC8Mhs/YPyk9YDK3mZmxdFgNYWbQKo+bFuiVFg0/X+dvg8w6fIBkw3?= =?us-ascii?Q?A0cDDaDyxxRVo4neJCzzdwFtZQmwKuy/B6sqc0HzXZW3pM3GDNCOnEmXFdCv?= =?us-ascii?Q?we0weOpv6U/zlUHYLap1rDJTxJVlIyQtYIbNBGSyy40ysW+srdNSGBuA+JsN?= =?us-ascii?Q?kQrsDw7io241Vk0glLiyumkgB0W92A+4i2hdWZuSeMuwgqH+oBMA9YEWT1kP?= =?us-ascii?Q?zNWncIfFyCLvOaAlX3/XKzEqZFuVNyd3SrHX94SeVpFtIe1xIWb2YfCG3/Kd?= =?us-ascii?Q?p2HsyvbngxqvyidkRgcGjcJoQklR9dSi0U9ob5RYYEbMiH/CIpGLN4ANT7wg?= =?us-ascii?Q?5jdq4/ah6zR1/CvYqNigF+GffYkfCljc4HHbumZG+uSD9UIk+MZ2xQMj7pPP?= =?us-ascii?Q?BfVaVJrq4QvvG2UPgcGcF0U12MeJSjfoE3GY7Y8vOZzC8LT+px+z6GYTz3aS?= =?us-ascii?Q?PsZvPS0MT4/ci0KyG80Z3QTZjbxFE+CMKxlJz4xkjR7sB58B1QxEH2XiuuOC?= =?us-ascii?Q?8MTV8zzVH5LCQw2H5k19IA3q9DHcOI5hsVbafV0YDyYUJQaWbevyLWJdSabK?= =?us-ascii?Q?LTc8pX/VuxTs3R8pGuEhAdCJLe74RU8sCvdf/wKIE05ynA+FIPizvZD/mRC3?= =?us-ascii?Q?i3Kr1i6Kyjh8oTcZ4xi6smnwbU9X7oMNyP+lizxnfhYDxnp939fM578vlzvW?= =?us-ascii?Q?frCA4fwqme5u+rX/O7lxauQ/hCDWkPSUEX0nMSZxautaseihJJvMyhZUehya?= =?us-ascii?Q?ci5Wxei/fGuG05pHexHMXJl8r/dpQp+BLyFd/ZNr6Bw5rvS8q+BRV9bsCCDZ?= =?us-ascii?Q?eMdssNhKMPC1KXSKDnMYAP/p?= 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: 3c954709-6d49-4564-9769-08d946b7cd17 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 11:09:08.1721 (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: 9IGAs5G/zl5f5ctnx+qXr/DJ+fXxWHgxryLI3B+XBuiI+z4sE6Y/57NPkAlbMWk+T4KCyGkVVhlXiofF0O1hpwmj+ua5cWu1ywxnFXJibYo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4740 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" > > > > > > Adding more rte_security and PMD maintainers into the loop. > > > > > > > > > > > > > > > > > For Tx inline processing, when RTE_SECURITY_TX_= OLOAD_NEED_MDATA is > > > > > > > > > > > > > > set, rte_security_set_pkt_metadata() needs to b= e called for pkts > > > > > > > > > > > > > > to associate a Security session with a mbuf bef= ore submitting > > > > > > > > > > > > > > to Ethdev Tx. This is apart from setting PKT_TX= _SEC_OFFLOAD in > > > > > > > > > > > > > > mbuf.ol_flags. rte_security_set_pkt_metadata() = is also used to > > > > > > > > > > > > > > set some opaque metadata in mbuf for PMD's use. > > > > > > > > > > > > > > This patch updates documentation that rte_secur= ity_set_pkt_metadata() > > > > > > > > > > > > > > should be called only with mbuf containing Laye= r 3 and above data. > > > > > > > > > > > > > > This behaviour is consistent with existing PMD'= s such as ixgbe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tx, not all net PMD's/HW can parse packet an= d identify > > > > > > > > > > > > > > L2 header and L3 header locations on Tx. This i= s inline with other > > > > > > > > > > > > > > Tx offloads requirements such as L3 checksum, L= 4 checksum offload, > > > > > > > > > > > > > > etc, where mbuf.l2_len, mbuf.l3_len etc, needs = to be set for > > > > > > > > > > > > > > HW to be able to generate checksum. Since Inlin= e IPSec is also > > > > > > > > > > > > > > such a Tx offload, some PMD's at least need mbu= f.l2_len to be > > > > > > > > > > > > > > valid to find L3 header and perform Outbound IP= Sec processing. > > > > > > > > > > > > > > Hence, this patch updates documentation to enfo= rce setting > > > > > > > > > > > > > > mbuf.l2_len while setting PKT_TX_SEC_OFFLOAD in= mbuf.ol_flags > > > > > > > > > > > > > > for Inline IPSec Crypto / Protocol offload proc= essing 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/features.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 library 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``, ``session_update``, > > > > > > > > > > > > > > ``session_stats_get``, ``session_destroy``, = ``set_pkt_metadata``, ``capabilities_get``. > > > > > > > > > > > > > > * **[provides] rte_eth_dev_info**: ``rx_offloa= d_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_SECURITY``, > > > > > > > > > > > > > > @@ -451,6 +452,7 @@ protocol operations. See se= curity 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``, ``session_update``, > > > > > > > > > > > > > > ``session_stats_get``, ``session_destroy``, = ``set_pkt_metadata``, ``get_userdata``, > > > > > > > > > > > > > > ``capabilities_get``. > > > > > > > > > > > > > > diff --git a/doc/guides/prog_guide/rte_security= .rst b/doc/guides/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 to the security session by the API > > > > > > > > > > > > > > > > > > > > > > > > > > > > For Inline Crypto and Inline protocol offload,= device specific defined metadata is > > > > > > > > > > > > > > updated in the mbuf using ``rte_security_set_p= kt_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 present 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`` h= ere? > > > > > > > > > > > > > > > > > > > > > > > > That is the semantics I was trying to define. I thi= nk below are the 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 need= s to be encrypted with a > > > > > > > > > > > > particular SA. Now pkt only has L3 and above data. > > > > > > > > > > > > 5. Do route_lookup() > > > > > > > > > > > > 6. add_l2hdr() which might be different from stripp= ed l2hdr. > > > > > > > > > > > > 7. Send packet out. > > > > > > > > > > > > > > > > > > > > > > > > The above sequence is what I believe the current po= ll mode worker thread in > > > > > > > > > > > > ipsec-secgw is following. > > > > > > > > > > > > > > > > > > > > > > That's just a sample app, it doesn't mean it has to b= e the only possible 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() implementatio= n really needs to know L3 hdr offset (not sure why?), > > > > > > > > > > Since rte_security_set_pkt_metadata() is PMD specific f= unction ptr call, we are currently doing some pre-processing > > > > > > > > > > here before submitting packet to inline IPSec via rte_e= th_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_security_set_pkt_metadata() call, then I think > > > > > > > > > > having a PMD specific callback is not much of use excep= t for saving SA priv data to rte_mbuf. > > > > > > > > > > > > > > > > > > > > > then I suppose we can add a requirement that l2_len h= as to be set properly 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_e= th_tx_burst() packet contents > > > > > > > > > at [mbuf.l2_len, mbuf.pkt_len) can't be modified? > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > > > > > > > > > Is that correct understanding? > > > > > > > > > If yes, I wonder how 2) will correlate with rte_eth_tx_pr= epare() concept? > > > > > > > > > > > > > > > > Since our PMD doesn't have a prepare function, I missed tha= t but, since > > > > > > > > rte_security_set_pkt_metadata() is only used for Inline Cry= pto/Protocol via > > > > > > > > a rte_eth_dev, and both rte_security_set_pkt_metadata() and= rte_eth_tx_prepare() > > > > > > > > are callbacks from same PMD, do you see any issue ? > > > > > > > > > > > > > > > > The restriction is from user side, data is not supposed to = be modified unless > > > > > > > > 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 al= lowed any more. > > > > > > You can still modify L2 header and IPSEC is only concerned abou= t L3 and above. > > > > > > > > > > > > I think insisting that rte_security_set_pkt_metadata() be calle= d after all L3 > > > > > > and above header modifications is no a problem. I guess existin= g ixgbe/txgbe > > > > > > PMD which are the ones only implementing the call back are alre= ady expecting the > > > > > > same ? > > > > > > > > > > AFAIK, no there are no such requirements for ixgbe or txgbe. > > > > > All that ixgbe callback does - store session related data inside = mbuf. > > > > > It's only expectation to have ESP trailer at the proper place (af= ter ICV): > > > > > > > > This implies rte_security_set_pkt_metadata() cannot be called when = mbuf does't > > > > have ESP trailer updated or when mbuf->pkt_len =3D 0 > > > > > > > > > > > > > > union ixgbe_crypto_tx_desc_md *mdata =3D (union ixgbe_crypto_tx_d= esc_md *) > > > > > rte_security_dynfield(m); > > > > > mdata->enc =3D 1; > > > > > mdata->sa_idx =3D ic_session->sa_index; > > > > > mdata->pad_len =3D ixgbe_crypto_compute_pad_len(m); > > > > > > > > > > Then this data will be used by tx_burst() function. > > > > So it implies that after above rte_security_set_pkt_metadata() call= , and before tx_burst(), > > > > mbuf data / packet len cannot be modified right as if modified, the= n tx_burst() > > > > will be using incorrect pad len ? > > > > > > No, pkt_len can be modified. > > > Though ESP trailer pad_len can't. > > > > > > > > > > > This patch is also trying to add similar restriction on when > > > > rte_security_set_pkt_metadata() should be called and what cannot be= done after > > > > calling rte_security_set_pkt_metadata(). > > > > > > No, I don't think it is really the same. > > > Also, IMO, inside ixgbe set_pkt_metadata() implementaion we probably = shouldn't silently imply > > > that ESP packet is already formed and trailer contains valid data. > > > In fact, I think this pad_len calculation can be moved to actual TX f= unction. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If your question is can't we do the preprocessing in rte_et= h_tx_prepare() for > > > > > > > > security, > > > > > > > > > > > > > > Yes, that was my thought. > > > > > > > > > > > > > > > my only argument was that since there is already a hit in > > > > > > > > rte_security_set_pkt_metadata() to PMD specific callback an= d > > > > > > > > struct rte_security_session is passed as an argument to it,= it is more benefitial 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 oth= er field contents) which > > > > > > > modifications are required for the packet. > > > > > > > > > > > > But the major issues I see are > > > > > > > > > > > > 1. tx_prepare() doesn't take rte_security_session as argument t= hough ol_flags has security flag. > > > > > > In our case, we need to know the security session details to= do things. > > > > > > > > > > I suppose you can store pointer to session (or so) inside mbuf in= rte_security_dynfield, no? > > > > > > > > We can do. But having to call PMD specific function call via rte_se= curity_set_pkt_metadata() > > > > just for storing session pointer in rte_security_dynfield consumes = unnecessary > > > > cycles per pkt. > > > > > > In fact there are two function calls: one for rte_security_set_pkt_me= tadata(), > > > second for instance->ops->set_pkt_metadata() callback. > > > Which off-course way too expensive for such simple operation. > > > Actually same thought for rte_security_get_userdata(). > > > Both of these functions belong to data-path and ideally have to be as= fast as possible. > > > Probably 21.11 is a right timeframe for that. > > > > > > > > > > > > > > 2. AFAIU tx_prepare() is not mandatory as per spec and even by = default disabled under compile time > > > > > > macro RTE_ETHDEV_TX_PREPARE_NOOP. > > > > > > 3. Even if we do tx_prepare(), rte_security_set_pkt_mdata() is = mandatory to associate > > > > > > struct rte_security_session to a pkt as unlike ol_flags, the= re is no direct space to do the same. > > > > > > > > > > Didn't get you here, obviously we do have rte_security_dynfield i= nside mbuf, > > > > > specially for that - to store secuiryt related data inside the mb= uf. > > > > > Yes your PMD has to request it at initialization time, but I supp= ose it is not a big deal. > > > > > > > > > > > So I think instead of enforcing yet another callback tx_prepare= () for inline security > > > > > > processing, it can be done via security specific set_pkt_metada= ta(). > > > > > > > > > > But what you proposing introduces new limitations and might exist= ing functionality. > > > > > BTW, if you don't like to use tx_prepare() - why doing these calc= ulations inside tx_burst() > > > > > itself is not an option? > > > > > > > > We can do things in tx_burst() but if we are doing it there, then w= e want to avoid having callback for > > > > rte_security_set_pkt_metadata(). > > > > > > > > Are you fine if we can update the spec that "When DEV_TX_OFFLOAD_SE= C_NEED_MDATA is not > > > > set, then, user needs to update struct rte_security_session's sess_= private_data in a in > > > > rte_security_dynfield like below ? > > > > > > > > > > > > > > > > static inline void > > > > inline_outb_mbuf_prepare(const struct rte_ipsec_session *ss, > > > > struct rte_mbuf *mb[], uint16_t num) > > > > { > > > > uint32_t i, ol_flags; > > > > > > > > ol_flags =3D ss->security.ol_flags & RTE_SECURITY_TX_OLOAD_= NEED_MDATA; > > > > for (i =3D 0; i !=3D num; i++) { > > > > > > > > mb[i]->ol_flags |=3D PKT_TX_SEC_OFFLOAD; > > > > > > > > if (ol_flags !=3D 0) > > > > rte_security_set_pkt_metadata(ss->security.= ctx, > > > > ss->security.ses, mb[i], NULL); > > > > else > > > > *rte_security_dynfield(mb[i]) =3D > > > > (uint64_t)ss->security.ses->sess_pr= ivate_data; > > > > > > > > > > > > If the above can be done, then in our PMD, we will not have a callb= ack for > > > > set_pkt_metadata() and DEV_TX_OFFLOAD_SEC_NEED_MDATA will also be n= ot set > > > > in capabilities. > > > > > > That's an interesting idea, but what you propose is the change in cur= rent rte_security API behaviour. > > > So all existing apps that use this API will have to be changed. > > > We'd better avoid such changes unless there is really good reason for= that. > > > So, I'd suggest to tweak your idea a bit: > > > > > > 1) change rte_security_set_pkt_metadata(): > > > if ops->set_pkt_metadata !=3D NULL, then call it (existing behaviour) > > > otherwise just: rte_security_dynfield(m) =3D sess->session_private_da= ta; > > > (fast-path) > > > > > > 2) consider to make rte_security_set_pkt_metadata() inline function. > > > We probably can have some special flag inside struct rte_security_ctx= , > > > or even store inside ctx a pointer to set_pkt_metadata() itself. > > > > After another thoughts some new flags might be better. > > Then later, if we'll realize that set_pkt_metadata() and get_useradata(= ) > > are not really used by PMDs, it might be easier to deprecate these call= backs. >=20 > Thanks, I agree with your thoughts. I'll submit a V2 with above change, n= ew flags and > set_pkt_metadata() and get_userdata() function pointers moved to rte_secu= rity_ctx for > review so that it can be targeted for 21.11. >=20 > Even with flags moving set_pkt_metadata() and get_userdata() function poi= nters is still needed > as we need to make rte_security_set_pkt_metadata() API inline while struc= t rte_security_ops is not > exposed to user. I think this is fine as it is inline with how fast path = function pointers > of rte_ethdev and rte_cryptodev are currently placed. My thought was we can get away with just flags only. Something like that: rte_security.h: ... enum { RTE_SEC_CTX_F_FAST_SET_MDATA =3D 0x1, RTE_SEC_CTX_F_FAST_GET_UDATA =3D 0x2, };=20 struct rte_security_ctx { void *device; /**< Crypto/ethernet device attached */ const struct rte_security_ops *ops; /**< Pointer to security ops for the device */ uint16_t sess_cnt; /**< Number of sessions attached to this context */ uint32_t flags; }; extern int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance, struct rte_security_session *sess, struct rte_mbuf *m, void *params);=20 static inline int rte_security_set_pkt_metadata(struct rte_security_ctx *instance, struct rte_security_session *sess, struct rte_mbuf *m, void *params) { /* fast-path */ if (instance->flags & RTE_SEC_CTX_F_FAST_SET_MDATA) { *rte_security_dynfield(m) =3D (rte_security_dynfield_t)(sessi= on->sess_priv_data); return 0; /* slow path */ } else return __rte_security_set_pkt_metadata (instance->device, sess,= m, params); } rte_security.c:=20 ... /* existing one, just renamed */ int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance, struct rte_security_session *sess, struct rte_mbuf *m, void *params) { #ifdef RTE_DEBUG RTE_PTR_OR_ERR_RET(sess, -EINVAL); RTE_PTR_OR_ERR_RET(instance, -EINVAL); RTE_PTR_OR_ERR_RET(instance->ops, -EINVAL); #endif RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->set_pkt_metadata, -ENOTSUP)= ; return instance->ops->set_pkt_metadata(instance->device, sess, m, params); } I think both ways are possible (flags vs actual func pointers) and both hav= e some pluses and minuses. I suppose the main choice here what do we think should be the future of set_pkt_metadata() and rte_security_get_userdata().=20 If we think that they will be useful for some future PMDs and we want to ke= ep them, then probably storing actual func pointers inside ctx is a better approach. If not, then flags seems like a better one, as in that case we can eventual= ly deprecate and remove these callbacks. >From what I see right now, custom callbacks seems excessive, and rte_security_dynfield is enough. But might be there are some future plans that would require them? =20 =20 >=20 > > > > > > > > As a brief code snippet: > > > > > > struct rte_security_ctx { > > > void *device; > > > /**< Crypto/ethernet device attached */ > > > const struct rte_security_ops *ops; > > > /**< Pointer to security ops for the device */ > > > uint16_t sess_cnt; > > > /**< Number of sessions attached to this context */ > > > + int (*set_pkt_mdata)(void *, struct rte_security_session *, str= uct rte_mbuf *, void *); > > > }; > > > > > > static inline int > > > rte_security_set_pkt_metadata(struct rte_security_ctx *instance, > > > struct rte_security_session *sess, > > > struct rte_mbuf *m, void *params) > > > { > > > /* fast-path */ > > > if (instance->set_pkt_mdata =3D=3D NULL) { > > > *rte_security_dynfield(m) =3D (rte_security_dynfield_t)(= session->sess_priv_data); > > > return 0; > > > /* slow path */ > > > } else > > > return instance->set_pkt_mdata(instance->device, sess, m, = params); > > > } > > > > > > That probably would be an ABI breakage (new fileld in rte_security_ct= x) and would require > > > some trivial changes for all existing PMDs that use RTE_SECURITY_TX_O= FLOAD_NEED_MDATA > > > (ctx_create()), but hopefully will benefit everyone. > > > > > > > > > > > > > > > > > > I'm fine to > > > > > > introduce a burst call for the same(I was thinking to propose i= t in future) to > > > > > > compensate for the overhead. > > > > > > > > > > > > If rte_security_set_pkt_metadata() was not a PMD specific funct= ion ptr call and > > > > > > rte_mbuf had space for struct rte_security_session pointer, > > > > > > > > > > But it does, see above. > > > > > In fact it even more flexible - because it is driver specific, yo= u are not limited to one 64-bit field. > > > > > If your PMD requires more data to be associated with mbuf > > > > > - you can request it via mbuf_dynfield and store there whatever i= s needed. > > > > > > > > > > > then then I guess it would have been better to do the way you p= roposed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This patch is trying to enforce semantics as above = so that > > > > > > > > > > > > rte_security_set_pkt_metadata() can predict what co= mes in the pkt when he is > > > > > > > > > > > > called. > > > > > > > > > > > > > > > > > > > > > > > > I also think above sequence is what Linux kernel st= ack or other stacks follow. > > > > > > > > > > > > Does it makes sense ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Once called, > > > > > > > > > > > > > > +Layer 3 and above data cannot be modified or m= oved around unless > > > > > > > > > > > > > > +``rte_security_set_pkt_metadata()`` is called = again. > > > > > > > > > > > > > > > > > > > > > > > > > > > > For inline protocol offloaded ingress traffic,= the application can register a > > > > > > > > > > > > > > pointer, ``userdata`` , in the security sessio= n. When the packet is received, > > > > > > > > > > > > > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbu= f/rte_mbuf_core.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 head= er starts. > > > > > > > > > > > > > > */ > > > > > > > > > > > > > > #define PKT_TX_SEC_OFFLOAD (1ULL << 43) > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > >