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 373A243A1B; Tue, 6 Feb 2024 23:51:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D2B74402E1; Tue, 6 Feb 2024 23:51:35 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id A34B7402CE for ; Tue, 6 Feb 2024 23:51:33 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1ACF45C00D9; Tue, 6 Feb 2024 17:51:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 06 Feb 2024 17:51:33 -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=1707259893; x=1707346293; bh=KD7V78tUJqtH+lOfhG1AARF6p+MUj8ySKz9CG9e79bI=; b= rwBlnJ73JzWrBeFr4RjTnZEgLfkCvqZyqeYxmpAhWxLNu/9PR/tARd+I8B11QLPE UnHE9aVvCpl5J4mfM6LxnWYODe6DktPI5HQ7twOLmkHogVFQr9AV2LmMuIie+XtL jXgAZiHyu+zNrKCC8Ys19pO0moN1G3H3vNHeK8D76Z7SUElmXmv88HkXnv2Pu43j umpEieTB8kJZDQpSDGs/7Kq295PKZvOFWjUiO0Akl/KGC45BQdmUz505FsbAEiaV 1yRFkzrwpwXdFI3GvvvGwt5Y+fYlrGcfMV+1WZOiJagVB6wL7uGHmzfovjQt3vL1 jNEOufbUDvSY1iwpnI2JXA== 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=1707259893; x= 1707346293; bh=KD7V78tUJqtH+lOfhG1AARF6p+MUj8ySKz9CG9e79bI=; b=S nTjNj7+m893tnNuNqBtG3ed69jLjLXvoSpA/TGUEUuf/WRWlsKaeSd6kTT+Uqii6 ztvjxjE5n0D0cjDNY+xn/IPWn2UWocavuAYQtxDnEyk9IU1w0LDPHm9jZ0SYbIY0 Je7M5pJrFDI625ZorZuAGmIpjYRwAWMnN9RBnhbrzkWFywKGDWq1U1Q2BAB4OXgJ grQ3ueNcoZFjM7Cl5NX0rEhkIoLwP8s8JmhZMhA7ctVo/VlQLRqEqQaLfOPN9lwS sMrHydS0pI/pmZT7mXtWae64ZakUD8MDD+tEjzCQa0ZsCVK+Boh2qXNEK33+fVou A3HhgbRGUqw9hwrfbx3Cw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtddugddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Feb 2024 17:51:30 -0500 (EST) From: Thomas Monjalon To: orika@nvidia.com, ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru, Gavin Li Cc: dev@dpdk.org, jiaweiw@nvidia.com, jerinj@marvell.com, bruce.richardson@intel.com, konstantin.v.ananyev@yandex.ru, Ajit Khaparde , Morten =?ISO-8859-1?Q?Br=F8rup?= , Jie Hai , Long Li , Dariusz Sosnowski , Hemant Agrawal , Maxime Coquelin Subject: Re: [RFC V1 1/1] net: extend VXLAN header to support more extensions Date: Tue, 06 Feb 2024 23:51:28 +0100 Message-ID: <16740437.geO5KgaWL5@thomas> In-Reply-To: <20240130112520.1971315-2-gavinl@nvidia.com> References: <20240130112520.1971315-1-gavinl@nvidia.com> <20240130112520.1971315-2-gavinl@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 30/01/2024 12:25, Gavin Li: > 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. So VXLAN GPE, GBP, and original ones will all use the same struct. Asking confirmation to other reviewers: - do we want to deprecate specific VXLAN GPE? - do we want to plan for VXLAN GPE removal? [...] > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* ethdev: The flow item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE`` is replaced with ``RTE_FLOW_ITEM_TYPE_VXLAN``. > + The item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE``, the struct ``rte_flow_item_vxlan_gpe``, its mask ``rte_flow_item_vxlan_gpe_mask``, > + and the header struct ``rte_vxlan_gpe_hdr`` with the macro ``RTE_ETHER_VXLAN_GPE_HLEN`` > + will be removed in DPDK 25.11. [...] > @@ -38,8 +38,65 @@ struct rte_vxlan_hdr { > rte_be32_t vx_vni; /**< VNI (24) + Reserved (8). */ > }; > struct { > - uint8_t flags; /**< Should be 8 (I flag). */ > - uint8_t rsvd0[3]; /**< Reserved. */ > + union { > + uint8_t flags; /**< Should be 8 (I flag). */ > + /* Flag bits defined by GPE */ > + struct { > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN > + uint8_t flag_o:1, > + flag_b:1, > + flag_p:1, > + flag_i_gpe:1, > + flag_ver:2, > + rsvd_gpe:2; > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t rsvd_gpe:2, > + flag_ver:2, > + flag_i_gpe:1, > + flag_p:1, > + flag_b:1, > + flag_o:1; > +#endif > + }; > + /* Flag bits defined by GBP */ > + struct { > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN > + uint8_t rsvd_gbp1:3, > + flag_i_gbp:1, > + rsvd_gbp2:3, > + flag_g:1; > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t flag_g:1, > + rsvd_gbp1:3, > + flag_i_gbp:1, > + rsvd_gbp2:3; > +#endif > + }; > + }; > + union { > + uint8_t rsvd0[3]; /**< Reserved. */ > + /* Overlap with rte_vxlan_gpe_hdr which is deprecated.*/ > + struct { > + uint8_t rsvd0_gpe[2]; /**< Reserved. */ > + uint8_t proto; /**< Next protocol. */ > + }; > + struct { > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN > + uint8_t rsvd0_gbp1:3, > + policy_applied:1, > + rsvd0_gbp2:2, > + dont_learn:1, > + rsvd0_gbp3:1; > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN > + uint8_t rsvd0_gbp1:1, > + dont_learn:1, > + rsvd0_gbp2:2, > + policy_applied:1, > + rsvd0_gbp3:3; > +#endif > + uint16_t policy_id; > + }; > + }; > uint8_t vni[3]; /**< VXLAN identifier. */ > uint8_t rsvd1; /**< Reserved. */ > }; Naming looks OK. Any different opinion?