DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev]  [RFC]  ethdev: introduce GENEVE header extension item
@ 2020-08-16 10:15 Shiri Kuzin
  2020-08-16 17:25 ` Stephen Hemminger
  2020-09-15  7:59 ` Ori Kam
  0 siblings, 2 replies; 4+ messages in thread
From: Shiri Kuzin @ 2020-08-16 10:15 UTC (permalink / raw)
  To: dev; +Cc: Slava Ovsiienko, NBU-Contact-Adrien Mazarguil, Raslan Darawsheh

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
  2020-08-16 10:15 [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item Shiri Kuzin
@ 2020-08-16 17:25 ` Stephen Hemminger
  2020-08-17  6:36   ` Shiri Kuzin
  2020-09-15  7:59 ` Ori Kam
  1 sibling, 1 reply; 4+ messages in thread
From: Stephen Hemminger @ 2020-08-16 17:25 UTC (permalink / raw)
  To: Shiri Kuzin
  Cc: dev, Slava Ovsiienko, NBU-Contact-Adrien Mazarguil, Raslan Darawsheh

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
  2020-08-16 17:25 ` Stephen Hemminger
@ 2020-08-17  6:36   ` Shiri Kuzin
  0 siblings, 0 replies; 4+ messages in thread
From: Shiri Kuzin @ 2020-08-17  6:36 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: dev, Slava Ovsiienko, NBU-Contact-Adrien Mazarguil, Raslan Darawsheh

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item
  2020-08-16 10:15 [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item Shiri Kuzin
  2020-08-16 17:25 ` Stephen Hemminger
@ 2020-09-15  7:59 ` Ori Kam
  1 sibling, 0 replies; 4+ messages in thread
From: Ori Kam @ 2020-09-15  7:59 UTC (permalink / raw)
  To: Shiri Kuzin, dev
  Cc: Slava Ovsiienko, NBU-Contact-Adrien Mazarguil, Raslan Darawsheh

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-15  8:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-16 10:15 [dpdk-dev] [RFC] ethdev: introduce GENEVE header extension item Shiri Kuzin
2020-08-16 17:25 ` Stephen Hemminger
2020-08-17  6:36   ` Shiri Kuzin
2020-09-15  7:59 ` Ori Kam

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git