From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7959EC433ED for ; Fri, 9 Apr 2021 10:56:18 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id EB4D8610D0 for ; Fri, 9 Apr 2021 10:56:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB4D8610D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marvell.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4C7904069F; Fri, 9 Apr 2021 12:56:17 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id 40FA14014D for ; Fri, 9 Apr 2021 12:56:16 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 139AuCYo026019; Fri, 9 Apr 2021 03:56:14 -0700 Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by mx0a-0016f401.pphosted.com with ESMTP id 37tftp8yp5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Apr 2021 03:56:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bmP5c+sFoCxcnb1hPz+3v7fM62U+h9XTZ//AmH3I2Q4QbgZcmCf/kZKWarI5UXkWnHmvgxMgAbjMMNOqPtNTmveiVYfY889yQ1z362g4JgosKQz8kWQ2m/xt+KKtzXvjPqV4jP9b5pwZAFNmw5p0Ihigla0Hri5VDzxhZ1YHLHeG33gpAu0gOWAeSARXsAHGPgfZvuT2CevWVqsRnSkSntx2eT+rDvPM3AGL1pRgciH9ZJI2kHcbc4y2rG7uYBpudGD8WPP3g+vSygfm10ea7tNsy14bLMG+QvleP3eeKL/p2RZj3N4/JXgb4uBU7M7Fe55b8klar5MrMupEwEQ8qw== 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=QkMjgP3cB4qqMwAIM5a9ak+OFtvKlO13i2VpaMPWoF4=; b=h9tLsRp0GWSvZckrLg+bevE0Yt8qEktid1eNLJIMfXvk3cF0V65+WLoMg3/8Cw0HKxhmtUmeak8COQMEPmwwyiQbPPmMZ2+oGzVV5x5dfWW4F9atn+3CtwO67ATV3PNv5AzqxH8uUngD05bc2Nf8uUNmnXKnQnBsgLi3KtCVTv+hnlOPP3sPx+KUldEnt1ZDycoNvrHtiqCgDjr2NkE0fBnAC/+CHUOgvdQmsRC0mJ0Y5Q4oFnXC+KOLt4yVilpV3mGO3/yfTApmm2VwHrE9fLfjRXHJgIx+ItuUMr+v9yr+FPNThUNgWFG6P/OYOKJRhnCArE4s1yLOj8WqhyV/Ew== 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.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QkMjgP3cB4qqMwAIM5a9ak+OFtvKlO13i2VpaMPWoF4=; b=fPxPUEyJsOtseh296/ATFaemtWxqAl+fuqeYNp+YKXskx5zqfybL/4ooqAdhNbH3tRF2QwzhlQaIC+C1EFOuVen4R3RAGSROxo0w7lG+6uzD1ROi0saRQrWYkcy4Ty9hF/11gy8Oe3P6IdO2oZN6ahjUg/rrVacH8vlj96BKtKA= Received: from MW2PR18MB2284.namprd18.prod.outlook.com (2603:10b6:907:10::16) by CO6PR18MB3971.namprd18.prod.outlook.com (2603:10b6:5:34a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.21; Fri, 9 Apr 2021 10:56:13 +0000 Received: from MW2PR18MB2284.namprd18.prod.outlook.com ([fe80::3168:cb00:6607:743f]) by MW2PR18MB2284.namprd18.prod.outlook.com ([fe80::3168:cb00:6607:743f%7]) with mapi id 15.20.4020.021; Fri, 9 Apr 2021 10:56:12 +0000 From: Akhil Goyal To: Olivier Matz , Tejasree Kondoj , Konstantin Ananyev CC: Radu Nicolau , 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: AQHXLEwiwVQqHlDsoUKbtlFLy2Bd7aqqdt6AgAGKr8A= Date: Fri, 9 Apr 2021 10:56:12 +0000 Message-ID: References: <20210408081720.23314-1-ktejasree@marvell.com> <20210408081720.23314-3-ktejasree@marvell.com> <20210408111007.GT1650@platinum> In-Reply-To: <20210408111007.GT1650@platinum> Accept-Language: en-US Content-Language: en-US X-Mentions: konstantin.ananyev@intel.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=marvell.com; x-originating-ip: [182.69.47.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8bb3eada-715e-4a53-648a-08d8fb461740 x-ms-traffictypediagnostic: CO6PR18MB3971: 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: AizzC8+AzmSofsBeO+sf0RLAXQZm0CYcWPmXSVHVRiCm6j2wJ2FmFVcPsdz3sI6KrifzIhDLd3juSL1no++UJGOB1r9EeHLPPDpRMCTQIfhgBWAfZbUnuYy98ZH70I3HUgBYpA7wNzzVXCCH24q/IX0INF0HaKpOiRCzZaAHvADzdhHvkAj8VIn6BoNEnGLBm4+2j3TkWFA2e5n3Xtoy2AP+X2Q5PyWOGprOp6ViH0IE8ez87ro4QLbZ3zPBQLvJ1igEk4/vPOAuJ5+O3c3ohxwptQ6zE1olUmPuc2wkTRVY8oJkVqNGG4MREW9qe90QezZ0TBhl+3dWOdxD2RxpN/qiUWSYGv0M5smq4WJgj/5nflG6Y8Klh72sYpQd69ZzA4YMmCvT8L1CiNpkXFZYGiIV2UZiGW3f6uYzu3jCr8R1DAGNvKsfdbnD5IAlEwBXEiVyhNFOxqs5Fx8v+BFKGX1+J8FEZdAQTL+mRwOXvyXLGVcNDeHe4/tMCjRwCwNlwuv15FvIK7BCmFcAfuXauTg8o9aCoNhyHMwV2Bv2ai0lSDD3o4DOQ4bSIY7wwr3LHuvRqiZyC1T6Fbueq9h0nUD5wbdzv59ZRC6V7AD/AcxoszxDpxhthA4ABqU81UzkZeqZkuhGfmIfAzM6A7G9IohxU8BI+zG0RRhJg8EGWOc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR18MB2284.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(366004)(76116006)(66556008)(186003)(38100700001)(316002)(7696005)(5660300002)(4326008)(64756008)(66446008)(478600001)(83380400001)(8936002)(66946007)(66476007)(33656002)(86362001)(71200400001)(52536014)(110136005)(54906003)(9686003)(26005)(2906002)(6506007)(8676002)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WGAdCpDR8oO/TLcZIFYvrHTC2KGaqQXrO8+yRXGURGsXNoYOBRbIZsRXLGfy?= =?us-ascii?Q?PU7DlKapWeSV8QS1wTexb3u2l6eYYdc4s5ezZtLAA3W5KP2qOqwgz9VB1XlY?= =?us-ascii?Q?rVAjpH2H9sQfsLl3zEEj9bdj9Gwep/9/u+XkP3G/M0YXrnWK9kKkfnZ/WuPB?= =?us-ascii?Q?6R2yvr3JOFuiKzC/TOzb19pn5SZsMjRmfs1Gwg1UKuN5IcmXfXAqCJldOM89?= =?us-ascii?Q?FGlm6nvuChu/xUExmclH39WY8hsftqpwIvO+C6Hc1KvGABFQ7bk0Kmec7DIm?= =?us-ascii?Q?BV2me/euriiN4+dCmqCKGAWDNj1m1JgWu0PJwvrh1KFjiYptJIxUs3Kfv1jz?= =?us-ascii?Q?A/w75xEbD++gFF3YjPRpGp5yswvhgOYvuI2HoK+lmy/465w0LnWZpGJagRQx?= =?us-ascii?Q?Ae4UWDu13PKRREfLnKOyjfoaNBJPVORPNjNM+i1JRrD6GRMaSiE2r8GJ0oEz?= =?us-ascii?Q?633E5EhgE8OLDV8RmxdK4nCkNrc4S4nAe+CbSsXJAx4e0ZjkqEHT8HgRScmp?= =?us-ascii?Q?2DtyUkJVJ6vM9uysn9IPOA6sNt8bqHW6ybOs0nFH0U3Ozr+O4JFwQHnOiz61?= =?us-ascii?Q?/6kVnpafa5i1Hcv3mB9IK6+lC7w9XEBnymiguF+L7SPU6FccesYlQRArTzXE?= =?us-ascii?Q?/UjEr/og1au3je1yQZHJHEoDUlofDsSaLM4ZAN5FJJ3wef6UTGM+lHfnrJkx?= =?us-ascii?Q?CWImUVD/SLixwGgZWqE6d/iyeEBePhL0twIrxQKLEAQtT2TunEtjH4Mf0h8w?= =?us-ascii?Q?p7JkNJjcyNGs5FB31rlz1i//q/wDDSwVqE7c5XVr23we8PTDJkY9ENuECiI2?= =?us-ascii?Q?n6QhttzgPybU8T/NKmLl/xg/SHxWYntzAMik6ItbgxTtmUS0kWOQZOh0WCcd?= =?us-ascii?Q?I02xYwNnAXvbbWbkSypAsHtQfvnGBUQcYn+z1TfulcO/nMdan41H/xKqowPB?= =?us-ascii?Q?JfYQlHZDb10gCOYi8H4DYR/zGm091IK9+o7ZiAlVjztsOjosTt2fyUGllB3i?= =?us-ascii?Q?SjB6sLirmZnQEZkWEHzmhxcD0sdBDrLCeSWdGEu8v7Vn+PojWMP9/OgsbFT5?= =?us-ascii?Q?XPM02iGOgsMHs+SsfIPJQcqymTjaHrKi2Sx/sHzyFpQ3VD5699JqBJ4dKxrA?= =?us-ascii?Q?AKptEQclf/MHQ3HOxeWB+L7mWt8jeZDqL7ri9p1wlcv1R3ohRUq4tEvRGDHx?= =?us-ascii?Q?rZ7a5gagcAAZ5nprc73xwYXuE1OY0F71ewfK7otRThiXF9RV4VZWAJZrWF5l?= =?us-ascii?Q?2niAnmRjyalEKJt2vcjeRFujhF6+KMwfq3NWht8oYv3td+VCNt0fvzMd7+x5?= =?us-ascii?Q?3iY=3D?= 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: MW2PR18MB2284.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bb3eada-715e-4a53-648a-08d8fb461740 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 10:56:12.7634 (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: PoBuDypF7p2XpjZ3P9aOOOWh87qQb9VgVX6a/v0pYjpoiHc/sj/Mox/yyGltb3Y0ZOztJ33up5UuuXDQWzP6OQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR18MB3971 X-Proofpoint-GUID: m7RnvbZ0mqUgA40i4kiNolvwJ8h80XRY X-Proofpoint-ORIG-GUID: m7RnvbZ0mqUgA40i4kiNolvwJ8h80XRY X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-09_05:2021-04-09, 2021-04-09 signatures=0 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 Olivier, > 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. > > */ >=20 > We arrive at the end of the values in packet type tunnel types, > and there is another pending patch that needs another tunnel type. >=20 > As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about > 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. >=20 > 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 standard = use case. #define RTE_PTYPE_TUNNEL_ESP_IN_UDP RTE_PTYPE_TUNNEL_ESP | RTE_PTYPE_= L4_UDP Will this be fine? >=20 > I think it is time to start thinking about how the packet_type > mbuf API can evolve to solve this issue. >=20 > By the way, the update of *rte_get_ptype_tunnel_name() is missing.