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 1EADAA0524; Tue, 13 Apr 2021 17:47:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE44E16113A; Tue, 13 Apr 2021 17:47:05 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 286B4161133 for ; Tue, 13 Apr 2021 17:47:03 +0200 (CEST) IronPort-SDR: co/q+SbkcvA3u8h/rC6xkEAnYb69AnAn93gp2zhZZzLqFRwakuqT7pwjUa3plwlF+oibNyczkK lU2UUvslonWg== X-IronPort-AV: E=McAfee;i="6200,9189,9953"; a="192314694" X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="192314694" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 08:46:31 -0700 IronPort-SDR: sKPgQhyWHRCTHy+ilvLSI9rQ5BGug5bNyITZIoe4ipf53tbTHKXnm4YKCI/1Gdk7nL6mRZZDFj iaVg+34hpNqw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="600385598" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga005.jf.intel.com with ESMTP; 13 Apr 2021 08:46:31 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 13 Apr 2021 08:46:31 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 13 Apr 2021 08:46:30 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Tue, 13 Apr 2021 08:46:30 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.100) 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.2106.2; Tue, 13 Apr 2021 08:46:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VgtgBHHSOM8xeDlb1EYxOkdl37+DcUnpbbcwZhn3/GkrBTLpSRyrE8HvOtnny150iNCTmF4na/LtCzO1ZFGPMOQy/JI3ljEh3s+3MxGoznBoyYrW0qK3+cFX2fATIfF3aJmNPtO+/Urut8TlBxHv/vPoMx2bexJhvktZb1rzy8HfSkq3lsNaDo8Fh47ONA4CN9iW4PmKv9eQdj8TJpRRwwju6Rg+tc0Wia1zF1rDGlXpmzSBl93XEZrdMAwkdUg/EBNn2TN+c7A9XmJo933e/xurEmEIC8kD7UDNBuqKTxuXU/ZE5bEGzODcaNNe0ITqQmrls0L2B2+DBSVJxh23HQ== 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=4oC0V0G3+RAbqmTZZVi3A0otKjcAp1fJgZg2ay2hkC4=; b=P6TJvyyRjp1Xvy1nRNc4LBeBDFvDlpVezhO9FO/6v6znBDrj2N9qh73Z/rU7x5ZBKUczDKSWcT2ENN+SGomETOcDH8h/+lQilff8CtczssQuCnGaJpBgE4e5Oju+HfwjemwbwUKCxv2IK7k0CCWDS3DYixX0u8mMKmGz8SqLh4qJRFTlAe8BPQbAqUfMDlXN3p7N6DfDL4c/IWsFjQs51ZqhWyL50zSbYUnBJO9edxmx0YhRbYK4Mybt7zqoFWWCuwZYm+oLj2xOg35wL6OzRMILxWw6TDAWhWhnZTJiCeSdGsoh2ceg7Xs8FOiMzDYvrM4iJV2gF86BNvlq7ztPHA== 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=4oC0V0G3+RAbqmTZZVi3A0otKjcAp1fJgZg2ay2hkC4=; b=ZDJNe5fDEzJIC8QzQDGbWGrFPJbeEBH5ssmPazITxLK74RECzjXDhh6OKA9FofRLTtXwCzJOMxtetS0hKErRImu86yKOWxzstR/Yg4ITkYdhImuP07GK+Sjc0I8BN8oaYC46peFuwH4t3J0oL3M8qeOltRW5e8auXUVaGObXcw4= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM5PR11MB1897.namprd11.prod.outlook.com (2603:10b6:3:112::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Tue, 13 Apr 2021 15:46:25 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a%3]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 15:46:25 +0000 From: "Ananyev, Konstantin" To: Akhil Goyal , Olivier Matz , Tejasree Kondoj CC: "Nicolau, Radu" , Anoob Joseph , Ankur Dwivedi , "Jerin Jacob Kollanukkaran" , "dev@dpdk.org" Thread-Topic: [EXT] Re: [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets Thread-Index: AQHXLEw7cjiAMCw9WUWdreKdNvODmKqqdt6AgAGOcgCABmzvgIAAJ6MQ Date: Tue, 13 Apr 2021 15:46:25 +0000 Message-ID: References: <20210408081720.23314-1-ktejasree@marvell.com> <20210408081720.23314-3-ktejasree@marvell.com> <20210408111007.GT1650@platinum> 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: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.255.184.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0d1e89f-7a81-4a2c-a3ed-08d8fe934bd2 x-ms-traffictypediagnostic: DM5PR11MB1897: 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: 52hPOyZUeDRN2P4tOjnT+6LH1QuI8jgz6zcZ+mTqmQnHsFzSbzLAeEUiLoPFiNM4ebsKhqBqRTtFxEXtvHbXzNI/DSXVDPS+KKaFxk1viddtSGiISx7DA9jMckEBzordCO3GgHDt7uvFkOe/MthaJ1+jH0pBnGvT5g27+bQhlApGSN4qDZM+04qYzPa6CEEKlHawTosDXH51mxgdmzWcyEOIR/RxCctIa+Llr9UDu8RvF7TFO9YcFrn1aREBIoMymfP6ajfHlIFG7ibqBYpNjza2NE2CyueTeN4FI7XBoHXlPwmGjOYWhoBJ29uQLIKt9cros8ILvMXsvPO0mbdnZLBF0Acq7j21vUo4WTvAQ/hCE5ttmDBz+1chnp3CepZgfMZmeegZb6XvXeveXkK+qcrYt6PCLfuNFEAdbMfwtlZZJzVkZbtDCRFXj9ov/j0bCsmy/86O5UGKiC7vfqTR+NpVPXZe1wOUcM7Y3glnZiGzKPSqwSdTKuL3fzsn2T7pdzTViIO02kzwMjWah3STcaXr2hpDjhSD9vbh6HO+KO5bX58ItOyrf8BtwH9DKPMxSzN72FK3mb/ZcoQiitbLTcysnLh3ikONtb3AbyKVAxQ= 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:(376002)(366004)(346002)(396003)(136003)(39860400002)(6506007)(83380400001)(8936002)(55016002)(55236004)(26005)(186003)(5660300002)(316002)(66446008)(7696005)(33656002)(76116006)(66556008)(52536014)(38100700002)(71200400001)(2906002)(9686003)(110136005)(54906003)(478600001)(4326008)(66946007)(64756008)(8676002)(66476007)(86362001)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ZnSZiAmBSNrwTvJaIvBDMUEx8o8HFTDM/3aaCY+kujPsGYJ41fUosKkc6jCD?= =?us-ascii?Q?vWq+HJIEP1inCxnzzdz0U45saN2hAQynmVbeD7snFqS4ZkAiEwKo5D86Ul2o?= =?us-ascii?Q?9YNJ2hULUhMfI0WVZjtd4bVOul7Jm+sfOlnM9RLDLuKc49xSzmE/0R0idrGR?= =?us-ascii?Q?1Tr36EOLGxvlEkSmFyDuLOUmK3bnPxsMoPMKii+PtctiiiaroA8Ma5V7Hy1j?= =?us-ascii?Q?zLZ+RofO5JyLxyfBgjedLfW154nNrBIbXDewuuNynh2AtOEtlxhQI2NziLMA?= =?us-ascii?Q?YoZ0ueQ9gMBVwSe11dMmBqc+XUQvN3AP5oRDFUMYATsHbc9n3MPgjZ+mBZY3?= =?us-ascii?Q?GvDkPNuSx/ZG3gL4VxhXswfPyhMu9UjUYLgVC9s68McXMJa9sa6rEJ7PuH3p?= =?us-ascii?Q?+XE04pqoyT0ebOYSL/kclBn9jvntXxNoNgIMy4CRFhGlXGs1GWwIHgEX1hIc?= =?us-ascii?Q?jmuzkapvU9DBnRqfCehuUXorRjH0FJArnqhD2t7I+xjybU7ChijrRYxYOYlj?= =?us-ascii?Q?mB5QQQfmWbMcTKq5uqlA+KgLosK6oVTREdqC5yPiJiEl5Q9k/Wp298NhJjtP?= =?us-ascii?Q?LOBvte/hUCp1LByKEPwEvin4wtcVI/kltD++l+uJZiuJwFhWb83OLD3U02D4?= =?us-ascii?Q?QN9Ij74yiLHI4diXwUIqMgcfe3t5fkCmzgtSEwLuWH5PbYDIDFWHhy0WlcLI?= =?us-ascii?Q?cY4s9loo6EVGRckM/82F8/oBZWDKHW5UaaVlT02BOB7JLI57b34Revz50JJi?= =?us-ascii?Q?n8YQQM22nLhLv2C8JiEdzchbWlvGuR3x/rfcROOgFLE7ApdznBPwugirtvJP?= =?us-ascii?Q?YBOTVNy/Q73jvlfuCszQupVjWdx/FNBsBuZIjeqpp1fgsRqKXjW69LKS7930?= =?us-ascii?Q?9MUefiQX7rv1m0VUxWsUh62YkR6ystL205yUrNFNJCS0arFVViNRjD5FaHR1?= =?us-ascii?Q?6U/n351u+6lnQq1SZ8y7kMNbr2qdkm8pe3d4QIS6ImivW8Hadoa7pb/jtl0J?= =?us-ascii?Q?XgJT7e4SLCwD7Q9N9YccmxYMFaTXRaNIJDuF/I+GAY9KGLyXmFOaLOYqVjJ6?= =?us-ascii?Q?pWAl4IxBwc/UaxsUb2YMEeayTAbXsTtOfhSBIbv9SsGQ4ApyWixEJLBmgizo?= =?us-ascii?Q?teAEzUqspa8kV38ccrkczyCYRLXO4I2qfhL4NXG9BhEeYbJM2LcHTGcXCeHN?= =?us-ascii?Q?+xKjNLI4zVfQ4xMHq+Misf7ESTyzRqPSR4jXiTziP/GTeaFA7Jdq+xmkZU9s?= =?us-ascii?Q?8SEV+XsoQ1ChaN25cvyKvRDrUUE4xiB3pQb3ox9HXKA3BfM7yWgiGWHrLUuQ?= =?us-ascii?Q?4GWpv0gWq0+48gTUoKL4O7sD?= 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: a0d1e89f-7a81-4a2c-a3ed-08d8fe934bd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 15:46:25.7819 (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: WyWfStYVl5Nzk1H1c6oFV/pkbbHj6pRNdIiX0L4RabPt7aUId7JqC8C07W6HmnfL7odtlnOfKDAO+oPTmyH6z50s50v+nQwPv2AL0LSI8XU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1897 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets 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" Hi Akhil, >=20 > Hi Olivier/ Konstantin, > > > On Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote: > > > > Adding new mbuf packet type for UDP encapsulated > > > > ESP packets. > > > > > > > > Signed-off-by: Tejasree Kondoj > > > > --- > > > > doc/guides/rel_notes/release_21_05.rst | 5 +++++ > > > > lib/librte_mbuf/rte_mbuf_ptype.h | 21 +++++++++++++++++++++ > > > > 2 files changed, 26 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/release_21_05.rst > > > b/doc/guides/rel_notes/release_21_05.rst > > > > index 5565c7637c..c9e9e2ec22 100644 > > > > --- a/doc/guides/rel_notes/release_21_05.rst > > > > +++ b/doc/guides/rel_notes/release_21_05.rst > > > > @@ -55,6 +55,11 @@ New Features > > > > Also, make sure to start the actual text at the margin. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > +* **Added new packet type for UDP-ESP packets in mbuf.** > > > > + > > > > + Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can > > > be > > > > + used to identify UDP encapsulated ESP packets. > > > > + > > > > * **Enhanced ethdev representor syntax.** > > > > > > > > * Introduced representor type of VF, SF and PF. > > > > diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h > > > b/lib/librte_mbuf/rte_mbuf_ptype.h > > > > index 17a2dd3576..bf92ce0c1a 100644 > > > > --- a/lib/librte_mbuf/rte_mbuf_ptype.h > > > > +++ b/lib/librte_mbuf/rte_mbuf_ptype.h > > > > @@ -491,6 +491,27 @@ extern "C" { > > > > * | 'destination port'=3D6635> > > > > */ > > > > #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP 0x0000d000 > > > > +/** > > > > + * ESP-in-UDP tunneling packet type (RFC 3948). > > > > + * > > > > + * Packet format: > > > > + * <'ether type'=3D0x0800 > > > > + * | 'version'=3D4, 'protocol'=3D17 > > > > + * | 'destination port'=3D4500> > > > > + * or, > > > > + * <'ether type'=3D0x86DD > > > > + * | 'version'=3D6, 'next header'=3D17 > > > > + * | 'destination port'=3D4500> > > > > + * or, > > > > + * <'ether type'=3D0x0800 > > > > + * | 'version'=3D4, 'protocol'=3D17 > > > > + * | 'source port'=3D4500> > > > > + * or, > > > > + * <'ether type'=3D0x86DD > > > > + * | 'version'=3D6, 'next header'=3D17 > > > > + * | 'source port'=3D4500> > > > > + */ > > > > +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP 0x0000e000 > > > > /** > > > > * Mask of tunneling packet types. > > > > */ > > > > > > We arrive at the end of the values in packet type tunnel types, > > > and there is another pending patch that needs another tunnel type. > > > > > > As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think abou= t > > > trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using > > > the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE. > > > > > > It is sensible, because it can be considered as an API change for > > > current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this > > > type is used by applications. > > > > It is OK to use combination of these two but with an assumption > > that a normal - IP-UDP packet when encrypted will be an IP-ESP packet > > And L4 types are reset from the mbuf->packet_type by the driver. > > @Konstantin Ananyev: Are you OK with this assumption? > > > > And, if we choose this path, then also we may need a macro in this file= , > > So that application doesn't have to combine that explicitly for a stand= ard use > > case. > > #define RTE_PTYPE_TUNNEL_ESP_IN_UDP RTE_PTYPE_TUNNEL_ESP | > > RTE_PTYPE_L4_UDP > > > > Will this be fine? > > > Can we proceed with this approach? I think we can safely use such combination inside ipsec-secgw app. About making it a new generic type - I am not so sure.=20 As Olivier already pointed out - it looks like an API/behaviour breakage to= me.=20 > Regards, > Akhil >=20 > > > > > > I think it is time to start thinking about how the packet_type > > > mbuf API can evolve to solve this issue. +1 Might be it needs to be reworked completely. > > > > > > By the way, the update of *rte_get_ptype_tunnel_name() is missing.