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 0094343AC3; Fri, 9 Feb 2024 11:12:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0BEE40697; Fri, 9 Feb 2024 11:12:23 +0100 (CET) Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com [103.168.172.150]) by mails.dpdk.org (Postfix) with ESMTP id 2A1644026A for ; Fri, 9 Feb 2024 11:12:22 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 947EC1380063; Fri, 9 Feb 2024 05:12:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 09 Feb 2024 05:12:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1707473541; x=1707559941; bh=FtR4b2mfisKSkqRJR96r/uCUVmJAVBrerVPP29bN9dM=; b= Acu7TA50+IyqVi5Lnhsoh9n1FMNDZJlHajIuZ0KJFWMtBmAJgw+m5ek8qBSocYzi z2/5EYRNH3I6xar0l9GFILzm2tNPYUJ5qX+ITUFMP0iDcJH+dF5/b7NIdnAJbUEL 7PNS2MChfCKaG9sT3TruJQ1RhYJp1HzcRg7rKWaEwvVa030icqbtzuQFsSbQ4a8v z15ce3FZobk8DOfIPGxbclsHlfH46Q+HQc3Pd2MEldaRxvr3eVzBlbuNqDAIfPGe 9pI6oUhGhDmRjbjezZKvRQXyfBZELoatCQp7WWprazN6J6X0k71F+qOaLxoG3S/j C0K1h/Gz+fz4UKDsV+V6HQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707473541; x= 1707559941; bh=FtR4b2mfisKSkqRJR96r/uCUVmJAVBrerVPP29bN9dM=; b=Z O6Qjm05vvRrKvd6TOqv5Aq7Os3v/SykqWeaDK8SgrJ4tEuL/afT+Anll2UsSurcR N26IZK172YC/OZg0sDHR1V0TYHTuMYGue5v6wwMw9/LiZEargqHzBKRY/mK919in y12N9Va3ERR6jjRjwlwwwuyluY5PyhJm1SsbUoSIB1YlSJzjfvi6F90QpC3BSoo7 U/p5IeDtulkiauElj1UE6ROssxeGpoOLQEWkZXQN3DiEBslpom1c9fVRW40UmvMM WBlX+GfMzEShbYRmTDQmtMRP6kfX1v0ztUVNOB5uGJeuG5H3yfHr75CRZpG/AJts 6DlZVSnBKQQvgzAWOhg0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtdeigdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedviedu vdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Feb 2024 05:12:20 -0500 (EST) From: Thomas Monjalon To: Gavin Li , orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, Ferruh Yigit Cc: dev@dpdk.org, jiaweiw@nvidia.com Subject: Re: [RFC V1 1/1] net: extend VXLAN header to support more extensions Date: Fri, 09 Feb 2024 11:12:18 +0100 Message-ID: <2384008.yKrmzQ4Hd0@thomas> In-Reply-To: <76ab3ffb-5f6b-4f16-a3a8-4e80f5afffcb@amd.com> References: <20240130112520.1971315-1-gavinl@nvidia.com> <20240130112520.1971315-2-gavinl@nvidia.com> <76ab3ffb-5f6b-4f16-a3a8-4e80f5afffcb@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 09/02/2024 00:54, Ferruh Yigit: > On 1/30/2024 11:25 AM, Gavin Li wrote: > > Currently, DPDK supports VXLAN and VXLAN-GPE with similar header > > structures and we are working on adding support for VXLAN-GBP which is > > another extension to VXLAN. More extension of VXLAN may be added in the > > future. > >=20 > > VXLAN and VXLAN-GBP use the same UDP port(4789) while VXLAN-GPE uses a > > different one, 4790. The three protocols have the same header length and > > overall similar header structure as below. > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R|R|R|R|I|R|R|R| Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VXLAN Network Identifier (VNI) | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Figure 1: VXLAN Header > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R|R|Ver|I|P|B|O| Reserved |Next Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VXLAN Network Identifier (VNI) | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Figure 2: VXLAN-GPE Header > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R| Group Policy ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VXLAN Network Identifier (VNI) | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Figure 3: VXLAN-GBP Extension > >=20 > > Both VXLAN-GPE and VXLAN-GBP extended VXLAN by redefining its reserved > > bits, which means the packets can be processed with same pattern and mo= st > > of the code can be reused. Instead of adding more new items by > > copying/pasting code for the VXLAN extensions in the future, it=E2=80= =99s better > > to use existing VXLAN infrastructure and add support code in it. > >=20 >=20 > Hi Gavin, >=20 > The motivation is to prevent code duplication, and the code mentioned is > the driver code, right? The motivation is mainly to provide a unified and more explicit API. > Overall OK to unify "struct rte_vxlan_hdr" although it makes the struct > a little complex, perhaps we can consider extraction some nested structs > as named struct, no strong opinion. >=20 >=20 > But not sure about removing the flow item types for VXLAN-GPE, or not > adding for VXLAN-GBP. >=20 > Think about a case user adding a rule, which has a item type as VXLAN > and in the protocol header some bits are set, lets say first word, last > byte is set, how driver will know if to take it as GPE "next protocol" > or "group policy id". The driver may decide depending on the UDP port and some distinguishing fla= gs. If you want to match on GBP, you should includes the GBP flag in your patte= rn, no need to use a separate item. > And if a specific HW detects VXLAN-GPE and VXLAN-GBP protocols as two > separate protocols, won't only having capability to describe VXLAN > protocol in SW be a limitation. I think the driver may know based on the flow rule. That's a good question about the item granularity. What is the separation between a different protocol and protocol options? How flow item should match protocol variations? My current thinking is that we should minimize the number of items. > If the target is to remove code duplication in the driver, can it be > accomplished by extracting code that parse the common fields of these > protocols? Driver code is not a concern as far as any driver can implement the API. > > In this patch, all the VXLAN extension header will be merged with VXLAN= as > > union if the overlapped field has different format among protocols. The > > existing VXLAN-GPE will be marked as deprecated and new extensions of > > VXLAN should be added to VXLAN instead of a new RTE item. > >=20 > > Signed-off-by: Gavin Li > > --- > > doc/guides/rel_notes/deprecation.rst | 5 +++ > > lib/ethdev/rte_flow.h | 13 +++++- > > lib/net/rte_vxlan.h | 67 ++++++++++++++++++++++++++-- > > 3 files changed, 80 insertions(+), 5 deletions(-) > >=20 > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_note= s/deprecation.rst > > index 81b93515cb..f9cf931b77 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -95,6 +95,11 @@ Deprecation Notices > > - ``rte_flow_item_pppoe`` > > - ``rte_flow_item_pppoe_proto_id`` > > =20 > > +* ethdev: The flow item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE`` is replaced w= ith ``RTE_FLOW_ITEM_TYPE_VXLAN``. > > + The item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE``, the struct ``rte_flow_ite= m_vxlan_gpe``, its mask ``rte_flow_item_vxlan_gpe_mask``, > > + and the header struct ``rte_vxlan_gpe_hdr`` with the macro ``RTE_ETH= ER_VXLAN_GPE_HLEN`` > > + will be removed in DPDK 25.11. > > + > > >=20 > We have 24.11 in between. Isn't it too soon? Should we remove at all?