From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:9LfCZXF5uXe3jzu_yebxptvuby7BFzVpIXSau0NtvwTEqDwsLY3N5Q>
<xme:9LfCZUVXNtdt98W2zZ1vLRUjv2o5fNAGGVhh6AYJ6tCc-Eau8KxBWWynkXszTtebn
NJ2sRAcsRkcMcWdEQ>
X-ME-Received: <xmr:9LfCZZJ-h7U5fNpzvBhd9Au8dutPc1ihGvTEEYYJnf55axpbYNZ53gLWCZrEFFdt69vdCBNdHYzCYHmniFGFOvO-6w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtddugddtfecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek
gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:9LfCZVF845X9RqHDtt4eFxvFreuAAIs8kWsj3urobPduT_uLHLlJFw>
<xmx:9LfCZdV4fEhwaH7zacEEn9L7vXfj0RSRW85oLSOsMSIxk2H9oYssTA>
<xmx:9LfCZQNt0Uwkf12Gb-sTSVX6Lfw8nPKICtaIeuskOr64n2tJ0ODXIA>
<xmx:9bfCZeW_rgCQR8pEFpaVwNh2ynsR4OHOpvc_5ZpFc8WS3GSCq6Sg3A>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
6 Feb 2024 17:51:30 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: orika@nvidia.com, ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru,
Gavin Li <gavinl@nvidia.com>
Cc: dev@dpdk.org, jiaweiw@nvidia.com, jerinj@marvell.com,
bruce.richardson@intel.com, konstantin.v.ananyev@yandex.ru,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>,
Jie Hai <haijie1@huawei.com>, Long Li <longli@microsoft.com>,
Dariusz Sosnowski <dsosnowski@nvidia.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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?