From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6E008A04B5; Sun, 10 Jan 2021 11:46:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00B1B140D63; Sun, 10 Jan 2021 11:46:27 +0100 (CET) Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by mails.dpdk.org (Postfix) with ESMTP id A647E140CD3 for ; Sun, 10 Jan 2021 11:46:24 +0100 (CET) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Sun, 10 Jan 2021 02:46:23 -0800 Received: from HQMAIL101.nvidia.com (172.20.187.10) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Jan 2021 10:46:19 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.48) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 10 Jan 2021 10:46:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Istb5ebK+Un/kTD7HUyzULfcA8tzvM+4pA8zhiiRmnITbwGuVoEMsNDjPOpYSwKVV+Rl+lfHPXXT6+4UeDo3dJKzKWYZI6K8VXG4zDQcznDizLrqwRyKLgLSshnwqHahxSu34T18n/NfDvth6AJOzLoJYmuAly8EYI5Wq4unox3MffUp377oniw1cD8lrs3yErp0GBTIoPv65hcUlYq7uoVM482kWdHI5wA8AAL9/GJxzX86d+M+EchIvMH91pKpqD1Wc1itsbmXEVG32YE41NhK3rLAgn8ow9oXUAnUaOqVzR+9o4CXcaNE8Lo0bJCWXN4JHIa6pmT8I7/sV/UenQ== 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=ysbtotMHQ4sNV3ntiVRBpFLQqgmaeo0gUOsmaPc0PXo=; b=oDK72oMbekm5ptLOHxVQFyRavKb0bjTMp4aXeX9Lhz4sRLYKulvhP8Xul9USNt604Frdu8PJ/kCGGpD2wfq7oI+9UZLgn8B9gdtdtwUKN6+ytpXXrG9uWI4tJB1HkzJs0HkHAEIWzXH336cuDpLw02xbWj8v3rwkvNOC65em6Cbyt/VhK/5lr1uCuq2Ujxk/exPKn0fSg/himBEGQ7AGSerXrd5UQ27vgHD6ggBXsjBNolLDowxYSJyQcrnH1lyKw2i53JQLN6b2PzojqJXFxs1RciTcQ8F6v9Vvp8c2HJuwMuYV6RzfC2OEO6VL3LXJuOuIdkbCwLnw+FyPo5sSrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from DM6PR12MB4987.namprd12.prod.outlook.com (2603:10b6:5:163::31) by DM6PR12MB4988.namprd12.prod.outlook.com (2603:10b6:5:16a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Sun, 10 Jan 2021 10:46:18 +0000 Received: from DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::e1e4:bf73:a753:2665]) by DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::e1e4:bf73:a753:2665%4]) with mapi id 15.20.3742.012; Sun, 10 Jan 2021 10:46:18 +0000 From: Ori Kam To: "Zhang, Qi Z" , NBU-Contact-Thomas Monjalon , "Yigit, Ferruh" , "Guo, Jia" , Andrew Rybchenko CC: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , Gregory Etelson Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri Thread-Index: AQHW2cME3bi3aSD2RUKkc8ehQpqtbaobPnMAgAC+FICAAAryAIAAK6SAgAAMvYCAAB75AIAAGmiAgACR9YCAAHoBgIAACNMAgAASpwCAAPGzAIACLVzw Date: Sun, 10 Jan 2021 10:46:17 +0000 Message-ID: References: <20201216085854.7842-1-jia.guo@intel.com> <29e83a3d-4c22-c200-ba03-7aae54a7e07b@intel.com> <3eb1ed08-01fe-d7d1-4540-e09a67e3077c@oktetlabs.ru> <1974177.35SpgSOlpP@thomas> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [147.236.145.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 201f2d66-9842-4106-f4c2-08d8b554f5f6 x-ms-traffictypediagnostic: DM6PR12MB4988: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1veiyS4VAvdFgUXKgDBZLM5OBXPI4DbZS4W+RCf9aDnZ/9GJo67VSBPOW/ut1wjwoSLVNN8QWhD6I1ufs/YKOPiXsAFEGueriua6JgCKPaDlErGVMxBPXSHQcy+x+YrTt7dKsHxX83zIQMGQslnJTikifk+EQeJeMvt45Z55G4dmSZVoAOGa38muGD3YFOsRlaFgjNnGOxU4kvGf4O+YHX0Q2IuXiai3p7s4FAmEL59fg9ja6IZCxa3g0sWFU1MJzp0EfQoMSP9hV38AbxwN0uWNdoD5VrxDHPxT3BZmeZNkLHToiusQk3DBShrpe/JEto9+JFwmoyI5a6OOLVagxE2/9iUwy2w1dazX43f9EMON9Lxb6coU3nzqD4LDvRYcsQ8ZQJ6NwfR++vuLrwZ3fV+t5s1RZ9bXpP0yPqsZSOWi9jJVG9nwG//N5hj7w+pIJMBTz5kp2F2gx7ySzLuS0YslKL01NS4CCR/mimGkjJGAnXFkZme9S8al1aZXWRTHtYeAgMgcGjfaFpvW+vRbGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4987.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(396003)(39850400004)(136003)(53546011)(54906003)(6506007)(110136005)(7696005)(966005)(71200400001)(66446008)(66946007)(186003)(8936002)(478600001)(64756008)(66476007)(66556008)(76116006)(86362001)(107886003)(5660300002)(9686003)(52536014)(45080400002)(55016002)(83380400001)(8676002)(33656002)(2906002)(26005)(316002)(4326008)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Y+fzvoey2iDs453U/1gyJ1NILCu8KcnFLDNjVkL2Hb+ILyYPTH5qlnY+43Ov?= =?us-ascii?Q?pKZz5TUcZFCax/G2VI/bPGb1zqfQH+OBGwamQArZSV50rruNBBOo9yZ1yPaB?= =?us-ascii?Q?H9EjyUbGhNj+a609gCLRXaC0D/Cv9xoBznrD5LJCqekz4W36k9O2i/UNbUB6?= =?us-ascii?Q?qhoe+A2zIszoY7YVkPyuPRNocCmUCG8gKcik8S16nGamYFhwmGX0UfqLB1GX?= =?us-ascii?Q?QFqbRHHLFbl0n7vfX+p61/ne1/4p3/w9jSGd95m9alc2knM5rq9u2fdnl6b0?= =?us-ascii?Q?YIHRsqGrh0vipNlnVU9myCbZwbWPFndSpylS9QtSTqyjlIXzjgGPuznDI2zv?= =?us-ascii?Q?8iGeJlrQnyMjMUZwYAgvbygvBKzKjkquri+aPgT9jeeqrefZxpIdq0nCtx0u?= =?us-ascii?Q?+8zX6xHd6b3rKzYi73R/RB89hm35UhJZf9b1xt3BDryMJ7zLw3gW31DQuFDg?= =?us-ascii?Q?zCtgCG23fcCJrzH0+T9YQXGuyJa73AlXyyuuosxbskf6joWuT5d3imT/jZFx?= =?us-ascii?Q?JVESblnxnT24IYVDbDMzbxAvkv60F4KCPqNpkDQkB6gj0D0j5txTknDJi+w1?= =?us-ascii?Q?SDo4IXvpZBTRhh32LJRwyOErdBPAYbmbOZ0lPtB6wmJbqBY0LZAwRpvanRnp?= =?us-ascii?Q?J11Pjso/9unOqoxcp2/iaCZDnha9nmGSBtVlLH33vfnwys8vfDnqKLyImQcg?= =?us-ascii?Q?79xcDqiDvFzawEe8jPC2ZrggzUSGfalHGLiWLsIeZr7iRaSfwT3cTXuKfLbv?= =?us-ascii?Q?JnnA3Qakct+r9w3oKipx0un2zRHjhwVtdNHeJy03S544rFMyweXP5u9ljvzk?= =?us-ascii?Q?tnE9ivZVrnyyVqyKYqqRhnxQINn9715k5eu7pwSFypHZhEPqoGiF9OktGcQP?= =?us-ascii?Q?6XyUrWVJEQgSRgW8HEVd/Ak+qVWqsF2Ocuw7FuACGFAg8yBbxzFM78Ewr5KS?= =?us-ascii?Q?sD4idhvVTAxkGixT5wTN4WnWqEsOJ818+F1k3xncMSk=3D?= 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: DM6PR12MB4987.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 201f2d66-9842-4106-f4c2-08d8b554f5f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2021 10:46:18.0128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hvdLV+bE7TZdiLN9Zbl53t11hXguEJXlhPOKJETBXmsBt9x8VJxHT0c4jgTt0IyM/3ZESWboOXb4i9OrzNSQHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4988 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610275583; bh=ysbtotMHQ4sNV3ntiVRBpFLQqgmaeo0gUOsmaPc0PXo=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To: CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ld-processed: x-ms-exchange-transport-forked:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-ms-exchange-senderadcheck: x-microsoft-antispam:x-microsoft-antispam-message-info: x-forefront-antispam-report:x-ms-exchange-antispam-messagedata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=XVOD/OGAzNp74RlRbqNZZR5SWkfkTm1Pha0TuE0E9pGZ5kYcKhjZONmrxHmwS9kDk m4nYXpqWROF9Tg163SlKAWYJyZ+rf9rilUslW1lXkZXxVv/h8zbXbQYN5SrcelvrG4 btM1kRuoc1x/UhA5LaXhqmJInyEpwmOU9QH0PmWm65yhO/ZPvKUrQi9tB6czw2jUUd At62nTjA6P1uPISjeETNUqgGgvUK24u2mQyDdKf2cerCzoyAbqsVigOwjawdpoOR34 GKfsOJ7MwPWzgqEdyE8GHKKPUwVFVb1gSTna/UGpTtVSxPCO08WKyru3Xn9yJgOAT9 jJCzEItbRCUiw== Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri 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, > -----Original Message----- > From: Zhang, Qi Z > Sent: Saturday, January 9, 2021 3:01 AM > Subject: RE: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for= ecpri >=20 >=20 >=20 > > -----Original Message----- > > From: Thomas Monjalon > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type f= or > ecpri > > > > 08/01/2021 10:29, Andrew Rybchenko: > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote: > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote: > > > >> From: Thomas Monjalon > > > >>> 07/01/2021 16:24, Zhang, Qi Z: > > > >>>> From: Thomas Monjalon > > > >>>>> 07/01/2021 13:47, Zhang, Qi Z: > > > >>>>>> From: Thomas Monjalon > > > >>>>>>> 07/01/2021 10:32, Guo, Jia: > > > >>>>>>>> From: Thomas Monjalon > > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo: > > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h > > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h > > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type { > > > >>>>>>>>>> RTE_TUNNEL_TYPE_IP_IN_GRE, > > > >>>>>>>>>> RTE_L2_TUNNEL_TYPE_E_TAG, > > > >>>>>>>>>> RTE_TUNNEL_TYPE_VXLAN_GPE, > > > >>>>>>>>>> + RTE_TUNNEL_TYPE_ECPRI, > > > >>>>>>>>>> RTE_TUNNEL_TYPE_MAX, > > > >>>>>>>>>> }; > > > >>>>>>>>> > > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11. > > > >>>>>>>>> Andrew decided to not remove this one because it is not yet > > > >>>>>>>>> completely replaced by rte_flow in all drivers. > > > >>>>>>>>> However, I am against continuing to update this API. > > > >>>>>>>>> The opposite work should be done: migrate to rte_flow. > > > >>>>>>>> > > > >>>>>>>> Agree but seems that the legacy api and driver legacy > > > >>>>>>>> implementation still keep in this release, and there is no a > > > >>>>>>>> general way to replace the legacy by rte_flow right now. > > > >>>>>>> > > > >>>>>>> I think rte_flow is a complete replacement with more features= . > > > >>>>>> > > > >>>>>> Thomas, I may not agree with this. > > > >>>>>> > > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by > > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp > > > >>>>>> port will be recognized as a specific tunnel packet type (e.g. > > > >>>>>> vxlan, vxlan-gpe, > > > >>>>> ecpri...) In Intel NIC, the API actually changes the > > > >>>>> configuration of the packet parser in HW but not add a filter > > > >>>>> rule and I guess all other devices may enable it in a similar w= ay. > > > >>>>>> so naturally it should be a device (port) level configuration > > > >>>>>> but not a rte_flow > > > >>>>> rule for match, encap, decap... > > > >>>>> > > > >>>>> I don't understand how it helps to identify an UDP port if ther= e > > > >>>>> is no rule for this tunnel. > > > >>>>> What is the usage? > > > >>>> > > > >>>> Yes, in general It is a rule, it matches a udp packet's dst port > > > >>>> and the action is > > > >>> "now the packet is identified as vxlan packet" then all other > > > >>> rte_flow rules that match for a vlxan as pattern will take effect= . > > > >>> but somehow, I think they are not rules in the same domain, just > > > >>> like we have dedicate API for mac/vlan filter, we'd better have a > > > >>> dedicate API for this also. ( RFC for Vxlan explains why we need > > > >>> this. > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf > .org%2Fhtml%2Frfc7348&data=3D04%7C01%7Corika%40nvidia.com%7C46b2 > d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a%7 > C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > mp;sdata=3DRYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&res > erved=3D0). > > > >>>> > > > >>>> "Destination Port: IANA has assigned the value 4789 for the VXLA= N > > > >>>> UDP port, and this value SHOULD be used by default as the > > > >>>> destination UDP port. Some early implementations of VXLAN have > > > >>>> used other values for the destination port. To enable > > > >>>> interoperability with these implementations, the destination por= t > > SHOULD be configurable." > > > >>> > > > >>> Yes the port number is free. > > > >>> But isn't it more natural to specify this port number as part of > > > >>> the rte_flow rule? > > > >> > > > >> I think if we have a rte_flow action type that can be used to set = a > > > >> packet's tunnel type xxx, like below #flow create eth/ipv4/udp por= t > > > >> is 4789/... action set_tunnel_type VxLAN / end then we may replace > > > >> it with rte_flow, but I'm not sure if it's necessary, please share > > > >> if you have a better idea. > > > > Of course we can specify the UDP port in rte_flow rule. > > Please check rte_flow_item_udp. > > That's a basic of rte_flow. >=20 > Its not about the pattern match, it's about the action, what we need is a > rte_flow action to "define a packet's tunnel type", but we don't have. >=20 > #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN >=20 > I think rte_eth_dev_udp_tunnel_port_add does this job well already, if we= plan > to move it to rte_flow, at least we need a replacement solution. >=20 Let me see if I understand it correctly. In your case, the issue is that you need to configure the HW to parse the p= acket correctly right? It is not about the matching it is about the configuration of the HW, you w= ish to tell the HW that the packet should be parsed by different means correct? If this is the case it sounds to me that you should use rte_flow and if the= =20 user adds the following rule: #flow create pattern eth / ivp4 / udp port is 4789 / .. action ..... You simply need to configure your HW to support the ecpri configuration. > > > > > > > > Isn't this more a device configuration than filtering, not sure > > > > about using rte_flow for this. > > > > > > +1 > > > > A device configuration? No, setting an UDP port is a stack configuratio= n. > > > > > > > >> BTW, are we going to move all other filter like mac , VLAN > > > >> filter/strip/insert into rte_flow finally? > > > > Yes I think it should be the direction. > > All of this can be achieved with rte_flow. > > > > > > > >> if that's the plan, though I don't have much inputs for this right > > > >> now, but I think we may not need to prevent new features be added > > > >> based on current API if it does not introduce more complexity and > > > >> not break anything. > > > > If we continue updating old API, we are just forking ourself: > > having 2 APIs for the same feature is a non-sense. > > We must remove APIs which are superseded by rte_flow. > >