[dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item

[dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item

[Shiri Kuzin]

The Geneve tunneling protocol is designed to allow
the user to specify some data context on the packet.
The header extension options is the mean intended
to present the user data. These ones are implemented
in TLV (Type-Length-Value) fashion, in order to
support these Geneve protocol feature we will
introduce the new item "rte_flow_item_geneve_option"

The support for new item will be added to testpmd
and include values and masks for the fields:
- class
- type
- data length
- data itself

The usage example:

"flow create 0 ingress pattern ipv4 / udp /
geneve / geneve_opt class is 102 type is 80
type mask ff data is 10002 data mask is
7fffffff / end actions drop / end "

New item will be added to testpmd to support
raw encap/decap action.

Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
---
 lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index da8bfa5..d04ee7c 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -347,6 +347,13 @@ enum rte_flow_item_type {
 	RTE_FLOW_ITEM_TYPE_GENEVE,
 
 	/**
+	 * Matches a GENEVE Variable Length Option.
+	 *
+	 * See struct rte_flow_item_geneve_option.
+	 */
+	RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
+
+	/**
 	 * Matches a VXLAN-GPE header.
 	 *
 	 * See struct rte_flow_item_vxlan_gpe.
@@ -1097,6 +1104,24 @@ struct rte_flow_item_geneve {
 #endif
 
 /**
+ * RTE_FLOW_ITEM_TYPE_GENEVE_OPTION.
+ *
+ * Matches a GENEVE Variable Length Option
+ */
+struct rte_flow_item_geneve_option {
+	rte_be16_t option_class;
+	uint8_t option_type;
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+	uint8_t length:5;
+	uint8_t rsvd0:3;
+#else
+	uint8_t rsvd0:3;
+	uint8_t length:5;
+#endif
+	    uint8_t data[];
+};
+
+/**
  * RTE_FLOW_ITEM_TYPE_VXLAN_GPE (draft-ietf-nvo3-vxlan-gpe-05).
  *
  * Matches a VXLAN-GPE header.
-- 
1.8.3.1

Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item

[Stephen Hemminger]

On Sun, 16 Aug 2020 10:15:03 +0000
Shiri Kuzin <shirik@nvidia.com> wrote:

> The Geneve tunneling protocol is designed to allow
> the user to specify some data context on the packet.
> The header extension options is the mean intended
> to present the user data. These ones are implemented
> in TLV (Type-Length-Value) fashion, in order to
> support these Geneve protocol feature we will
> introduce the new item "rte_flow_item_geneve_option"
> 
> The support for new item will be added to testpmd
> and include values and masks for the fields:
> - class
> - type
> - data length
> - data itself
> 
> The usage example:
> 
> "flow create 0 ingress pattern ipv4 / udp /
> geneve / geneve_opt class is 102 type is 80
> type mask ff data is 10002 data mask is
> 7fffffff / end actions drop / end "
> 
> New item will be added to testpmd to support
> raw encap/decap action.
> 
> Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
> ---
>  lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index da8bfa5..d04ee7c 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -347,6 +347,13 @@ enum rte_flow_item_type {
>  	RTE_FLOW_ITEM_TYPE_GENEVE,
>  
>  	/**
> +	 * Matches a GENEVE Variable Length Option.
> +	 *
> +	 * See struct rte_flow_item_geneve_option.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
> +
> +	/**

Please don't break ABI by putting items in middle of enum.
New items should go at the end.
enum changes the val

Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item

[Shiri Kuzin]

Thanks, PSB.

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, August 16, 2020 8:26 PM
> To: Shiri Kuzin <shirik@nvidia.com>
> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-
> Contact-Adrien Mazarguil <adrien.mazarguil@6wind.com>; Raslan
> Darawsheh <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension
> item
> 
> On Sun, 16 Aug 2020 10:15:03 +0000
> Shiri Kuzin <shirik@nvidia.com> wrote:
> 
> > The Geneve tunneling protocol is designed to allow the user to specify
> > some data context on the packet.
> > The header extension options is the mean intended to present the user
> > data. These ones are implemented in TLV (Type-Length-Value) fashion,
> > in order to support these Geneve protocol feature we will introduce
> > the new item "rte_flow_item_geneve_option"
> >
> > The support for new item will be added to testpmd and include values
> > and masks for the fields:
> > - class
> > - type
> > - data length
> > - data itself
> >
> > The usage example:
> >
> > "flow create 0 ingress pattern ipv4 / udp / geneve / geneve_opt class
> > is 102 type is 80 type mask ff data is 10002 data mask is 7fffffff /
> > end actions drop / end "
> >
> > New item will be added to testpmd to support raw encap/decap action.
> >
> > Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
> > ---
> >  lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index da8bfa5..d04ee7c 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -347,6 +347,13 @@ enum rte_flow_item_type {
> >  	RTE_FLOW_ITEM_TYPE_GENEVE,
> >
> >  	/**
> > +	 * Matches a GENEVE Variable Length Option.
> > +	 *
> > +	 * See struct rte_flow_item_geneve_option.
> > +	 */
> > +	RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
> > +
> > +	/**
> 
> Please don't break ABI by putting items in middle of enum.
> New items should go at the end.
> enum changes the val

Yes, thank you for the note.
I will move it to the end of the enum.

Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item

[Ori Kam]

Hi 
PSB,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Shiri Kuzin
> 
> The Geneve tunneling protocol is designed to allow
> the user to specify some data context on the packet.
> The header extension options is the mean intended
> to present the user data. These ones are implemented
> in TLV (Type-Length-Value) fashion, in order to
> support these Geneve protocol feature we will
> introduce the new item "rte_flow_item_geneve_option"
> 
> The support for new item will be added to testpmd
> and include values and masks for the fields:
> - class
> - type
> - data length
> - data itself
> 
> The usage example:
> 
> "flow create 0 ingress pattern ipv4 / udp /
> geneve / geneve_opt class is 102 type is 80
> type mask ff data is 10002 data mask is
> 7fffffff / end actions drop / end "
> 

Can we have in the same flow number of such items?

> New item will be added to testpmd to support
> raw encap/decap action.
> 
> Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
> ---
>  lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index da8bfa5..d04ee7c 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -347,6 +347,13 @@ enum rte_flow_item_type {
>  	RTE_FLOW_ITEM_TYPE_GENEVE,
> 
>  	/**
> +	 * Matches a GENEVE Variable Length Option.
> +	 *
> +	 * See struct rte_flow_item_geneve_option.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
> +
> +	/**
>  	 * Matches a VXLAN-GPE header.
>  	 *
>  	 * See struct rte_flow_item_vxlan_gpe.
> @@ -1097,6 +1104,24 @@ struct rte_flow_item_geneve {
>  #endif
> 
>  /**
> + * RTE_FLOW_ITEM_TYPE_GENEVE_OPTION.
> + *
> + * Matches a GENEVE Variable Length Option
> + */
> +struct rte_flow_item_geneve_option {
> +	rte_be16_t option_class;
> +	uint8_t option_type;
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> +	uint8_t length:5;
> +	uint8_t rsvd0:3;
> +#else
> +	uint8_t rsvd0:3;
> +	uint8_t length:5;
> +#endif
> +	    uint8_t data[];

I think it will be better to use pointer and not empty array.
Other option is to always take the max possible data size 32.

> +};
> +
> +/**
>   * RTE_FLOW_ITEM_TYPE_VXLAN_GPE (draft-ietf-nvo3-vxlan-gpe-05).
>   *
>   * Matches a VXLAN-GPE header.
> --
> 1.8.3.1

Best,
Ori