DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
@ 2020-04-23 18:30 Dekel Peled
  2020-04-25 14:00 ` Andrew Rybchenko
  2020-05-03  7:17 ` [dpdk-dev] [PATCH v2] " Dekel Peled
  0 siblings, 2 replies; 10+ messages in thread
From: Dekel Peled @ 2020-04-23 18:30 UTC (permalink / raw)
  To: orika, john.mcnamara, marko.kovacevic, thomas, ferruh.yigit, arybchenko
  Cc: dev, asafp

Specified pattern may be translated in different manner.
For example the pattern "eth / ipv4" can be translated to match
untagged packets only, since the pattern doesn't specify a vlan item.
It can also be translated to match both tagged and untagged packets,
for the same reason.
This patch updates the rte_flow documentation to clearly specify the
required pattern to use.
For example:
To match tagged ipv4 packets, the pattern "eth type is 0x8100 /
vlan / ipv4 / end" should be used.
To match untagged ipv4 packets, the pattern "eth type is 0x0800 /
ipv4 / end" should be used.
To match both tagged and untagged packets, the pattern "eth / end"
should be used.

Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
 doc/guides/prog_guide/rte_flow.rst | 8 ++++++++
 lib/librte_ethdev/rte_flow.h       | 9 +++++++++
 2 files changed, 17 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index cf4368e..0d1c305 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -905,6 +905,12 @@ so-called layer 2.5 pattern items such as ``RTE_FLOW_ITEM_TYPE_VLAN``. In
 the latter case, ``type`` refers to that of the outer header, with the inner
 EtherType/TPID provided by the subsequent pattern item. This is the same
 order as on the wire.
+If the ``type`` field contains a TPID value, then only tagged packets will match
+the pattern.
+If the ``type`` field contains another EtherType value, then only untagged
+packets will match the pattern.
+If the ``ETH`` item is the only item in the pattern, and the ``type`` field is
+not specified, then both tagged and untagged packets will match the pattern.
 
 - ``dst``: destination MAC.
 - ``src``: source MAC.
@@ -919,6 +925,8 @@ Matches an 802.1Q/ad VLAN tag.
 The corresponding standard outer EtherType (TPID) values are
 ``RTE_ETHER_TYPE_VLAN`` or ``RTE_ETHER_TYPE_QINQ``. It can be overridden by the
 preceding pattern item.
+If a ``VLAN`` item is present in the pattern, then only tagged packets will
+match the pattern.
 
 - ``tci``: tag control information.
 - ``inner_type``: inner EtherType or TPID.
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 132b44e..178e87e 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -710,6 +710,13 @@ struct rte_flow_item_raw {
  * the latter case, @p type refers to that of the outer header, with the
  * inner EtherType/TPID provided by the subsequent pattern item. This is the
  * same order as on the wire.
+ * If the @p type field contains a TPID value, then only tagged packets will
+ * match the pattern.
+ * If the @p type field contains another EtherType value, then only untagged
+ * packets will match the pattern.
+ * If the @p ETH item is the only item in the pattern, and the @p type field
+ * is not specified, then both tagged and untagged packets will match the
+ * pattern.
  */
 struct rte_flow_item_eth {
 	struct rte_ether_addr dst; /**< Destination MAC. */
@@ -734,6 +741,8 @@ struct rte_flow_item_eth {
  * The corresponding standard outer EtherType (TPID) values are
  * RTE_ETHER_TYPE_VLAN or RTE_ETHER_TYPE_QINQ. It can be overridden by
  * the preceding pattern item.
+ * If a @p VLAN item is present in the pattern, then only tagged packets will
+ * match the pattern.
  */
 struct rte_flow_item_vlan {
 	rte_be16_t tci; /**< Tag control information. */
-- 
1.8.3.1


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

* Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
  2020-04-23 18:30 [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items Dekel Peled
@ 2020-04-25 14:00 ` Andrew Rybchenko
  2020-04-26  9:18   ` Dekel Peled
  2020-05-03  7:17 ` [dpdk-dev] [PATCH v2] " Dekel Peled
  1 sibling, 1 reply; 10+ messages in thread
From: Andrew Rybchenko @ 2020-04-25 14:00 UTC (permalink / raw)
  To: Dekel Peled, orika, john.mcnamara, marko.kovacevic, thomas, ferruh.yigit
  Cc: dev, asafp

On 4/23/20 9:30 PM, Dekel Peled wrote:
> Specified pattern may be translated in different manner.
> For example the pattern "eth / ipv4" can be translated to match
> untagged packets only, since the pattern doesn't specify a vlan item.

vlan -> VLAN

> It can also be translated to match both tagged and untagged packets,
> for the same reason.
> This patch updates the rte_flow documentation to clearly specify the
> required pattern to use.
> For example:
> To match tagged ipv4 packets, the pattern "eth type is 0x8100 /
> vlan / ipv4 / end" should be used.

Isn't eth / vlan / ipv4 /end sufficient? What's the difference?
I guess later should allow any VLAN TPID, but it is greyish
since it is HW dependent.

> To match untagged ipv4 packets, the pattern "eth type is 0x0800 /
> ipv4 / end" should be used.

What about eth / ipv4 / end?
Does usage of ipv4 assume that EtherType is 0x0800?

> To match both tagged and untagged packets, the pattern "eth / end"
> should be used.

The interesting question is what should be used if I want
either tagged or untagged IPv4 packets. I think it worse
to mention to make the picture complete.

> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 8 ++++++++
>  lib/librte_ethdev/rte_flow.h       | 9 +++++++++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index cf4368e..0d1c305 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -905,6 +905,12 @@ so-called layer 2.5 pattern items such as ``RTE_FLOW_ITEM_TYPE_VLAN``. In
>  the latter case, ``type`` refers to that of the outer header, with the inner
>  EtherType/TPID provided by the subsequent pattern item. This is the same
>  order as on the wire.
> +If the ``type`` field contains a TPID value, then only tagged packets will match
> +the pattern.

Shouldn't we emphasis that "tagged packets with specified TPID
will match the pattern." since tagged packets could have
various TPIDs.

> +If the ``type`` field contains another EtherType value, then only untagged
> +packets will match the pattern.

I'm afraid "another EtherType" is too ambiguous.
"non-TPID EtherType" is ambiguous as well and HW
dependent. May be it is better to remove the sentence
completely.

> +If the ``ETH`` item is the only item in the pattern, and the ``type`` field is
> +not specified, then both tagged and untagged packets will match the pattern.
>  
>  - ``dst``: destination MAC.
>  - ``src``: source MAC.
> @@ -919,6 +925,8 @@ Matches an 802.1Q/ad VLAN tag.
>  The corresponding standard outer EtherType (TPID) values are
>  ``RTE_ETHER_TYPE_VLAN`` or ``RTE_ETHER_TYPE_QINQ``. It can be overridden by the
>  preceding pattern item.
> +If a ``VLAN`` item is present in the pattern, then only tagged packets will
> +match the pattern.
>  
>  - ``tci``: tag control information.
>  - ``inner_type``: inner EtherType or TPID.
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 132b44e..178e87e 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -710,6 +710,13 @@ struct rte_flow_item_raw {
>   * the latter case, @p type refers to that of the outer header, with the
>   * inner EtherType/TPID provided by the subsequent pattern item. This is the
>   * same order as on the wire.
> + * If the @p type field contains a TPID value, then only tagged packets will
> + * match the pattern.
> + * If the @p type field contains another EtherType value, then only untagged
> + * packets will match the pattern.
> + * If the @p ETH item is the only item in the pattern, and the @p type field
> + * is not specified, then both tagged and untagged packets will match the
> + * pattern.
>   */
>  struct rte_flow_item_eth {
>  	struct rte_ether_addr dst; /**< Destination MAC. */
> @@ -734,6 +741,8 @@ struct rte_flow_item_eth {
>   * The corresponding standard outer EtherType (TPID) values are
>   * RTE_ETHER_TYPE_VLAN or RTE_ETHER_TYPE_QINQ. It can be overridden by
>   * the preceding pattern item.
> + * If a @p VLAN item is present in the pattern, then only tagged packets will
> + * match the pattern.
>   */
>  struct rte_flow_item_vlan {
>  	rte_be16_t tci; /**< Tag control information. */
> 


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

* Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
  2020-04-25 14:00 ` Andrew Rybchenko
@ 2020-04-26  9:18   ` Dekel Peled
  2020-04-26 17:02     ` Stephen Hemminger
  0 siblings, 1 reply; 10+ messages in thread
From: Dekel Peled @ 2020-04-26  9:18 UTC (permalink / raw)
  To: Andrew Rybchenko, Ori Kam, john.mcnamara, marko.kovacevic,
	Thomas Monjalon, ferruh.yigit
  Cc: dev, Asaf Penso

Thanks, PSB.

> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Saturday, April 25, 2020 5:00 PM
> To: Dekel Peled <dekelp@mellanox.com>; Ori Kam <orika@mellanox.com>;
> john.mcnamara@intel.com; marko.kovacevic@intel.com; Thomas Monjalon
> <thomas@monjalon.net>; ferruh.yigit@intel.com
> Cc: dev@dpdk.org; Asaf Penso <asafp@mellanox.com>
> Subject: Re: [PATCH] doc: refine ethernet and VLAN flow rule items
> 
> On 4/23/20 9:30 PM, Dekel Peled wrote:
> > Specified pattern may be translated in different manner.
> > For example the pattern "eth / ipv4" can be translated to match
> > untagged packets only, since the pattern doesn't specify a vlan item.
> 
> vlan -> VLAN

I will change to uppercase.

> 
> > It can also be translated to match both tagged and untagged packets,
> > for the same reason.
> > This patch updates the rte_flow documentation to clearly specify the
> > required pattern to use.
> > For example:
> > To match tagged ipv4 packets, the pattern "eth type is 0x8100 / vlan /
> > ipv4 / end" should be used.
> 
> Isn't eth / vlan / ipv4 /end sufficient? What's the difference?
> I guess later should allow any VLAN TPID, but it is greyish since it is HW
> dependent.

In the example I wanted to show explicit rule, to emphasize the importance of detailed pattern structure.

> 
> > To match untagged ipv4 packets, the pattern "eth type is 0x0800 /
> > ipv4 / end" should be used.
> 
> What about eth / ipv4 / end?
> Does usage of ipv4 assume that EtherType is 0x0800?

Same as above.

> 
> > To match both tagged and untagged packets, the pattern "eth / end"
> > should be used.
> 
> The interesting question is what should be used if I want either tagged or
> untagged IPv4 packets. I think it worse to mention to make the picture
> complete.

To match any IPV4 packet, either tagged or untagged, need to apply two rules.
One for tagged packets and the other for untagged packets.
I will add this example as well.

> 
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > ---
> >  doc/guides/prog_guide/rte_flow.rst | 8 ++++++++
> >  lib/librte_ethdev/rte_flow.h       | 9 +++++++++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index cf4368e..0d1c305 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -905,6 +905,12 @@ so-called layer 2.5 pattern items such as
> > ``RTE_FLOW_ITEM_TYPE_VLAN``. In  the latter case, ``type`` refers to
> > that of the outer header, with the inner  EtherType/TPID provided by
> > the subsequent pattern item. This is the same  order as on the wire.
> > +If the ``type`` field contains a TPID value, then only tagged packets
> > +will match the pattern.
> 
> Shouldn't we emphasis that "tagged packets with specified TPID will match
> the pattern." since tagged packets could have various TPIDs.

Agree, I will update.

> 
> > +If the ``type`` field contains another EtherType value, then only
> > +untagged packets will match the pattern.
> 
> I'm afraid "another EtherType" is too ambiguous.
> "non-TPID EtherType" is ambiguous as well and HW dependent. May be it is
> better to remove the sentence completely.

I think this sentence is important in order to emphasize the untagged packets case.
How about "Otherwise, only untagged packets will match the pattern."?

> 
> > +If the ``ETH`` item is the only item in the pattern, and the ``type``
> > +field is not specified, then both tagged and untagged packets will match
> the pattern.
> >
> >  - ``dst``: destination MAC.
> >  - ``src``: source MAC.
> > @@ -919,6 +925,8 @@ Matches an 802.1Q/ad VLAN tag.
> >  The corresponding standard outer EtherType (TPID) values are
> > ``RTE_ETHER_TYPE_VLAN`` or ``RTE_ETHER_TYPE_QINQ``. It can be
> > overridden by the  preceding pattern item.
> > +If a ``VLAN`` item is present in the pattern, then only tagged
> > +packets will match the pattern.
> >
> >  - ``tci``: tag control information.
> >  - ``inner_type``: inner EtherType or TPID.
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index 132b44e..178e87e 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -710,6 +710,13 @@ struct rte_flow_item_raw {
> >   * the latter case, @p type refers to that of the outer header, with the
> >   * inner EtherType/TPID provided by the subsequent pattern item. This is
> the
> >   * same order as on the wire.
> > + * If the @p type field contains a TPID value, then only tagged
> > + packets will
> > + * match the pattern.
> > + * If the @p type field contains another EtherType value, then only
> > + untagged
> > + * packets will match the pattern.
> > + * If the @p ETH item is the only item in the pattern, and the @p
> > + type field
> > + * is not specified, then both tagged and untagged packets will match
> > + the
> > + * pattern.
> >   */
> >  struct rte_flow_item_eth {
> >  	struct rte_ether_addr dst; /**< Destination MAC. */ @@ -734,6
> +741,8
> > @@ struct rte_flow_item_eth {
> >   * The corresponding standard outer EtherType (TPID) values are
> >   * RTE_ETHER_TYPE_VLAN or RTE_ETHER_TYPE_QINQ. It can be
> overridden by
> >   * the preceding pattern item.
> > + * If a @p VLAN item is present in the pattern, then only tagged
> > + packets will
> > + * match the pattern.
> >   */
> >  struct rte_flow_item_vlan {
> >  	rte_be16_t tci; /**< Tag control information. */
> >


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

* Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
  2020-04-26  9:18   ` Dekel Peled
@ 2020-04-26 17:02     ` Stephen Hemminger
  2020-04-27  6:52       ` Ori Kam
  0 siblings, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2020-04-26 17:02 UTC (permalink / raw)
  To: Dekel Peled
  Cc: Andrew Rybchenko, Ori Kam, john.mcnamara, marko.kovacevic,
	Thomas Monjalon, ferruh.yigit, dev, Asaf Penso

On Sun, 26 Apr 2020 09:18:54 +0000
Dekel Peled <dekelp@mellanox.com> wrote:

> Thanks, PSB.
> 
> > -----Original Message-----
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> > Sent: Saturday, April 25, 2020 5:00 PM
> > To: Dekel Peled <dekelp@mellanox.com>; Ori Kam <orika@mellanox.com>;
> > john.mcnamara@intel.com; marko.kovacevic@intel.com; Thomas Monjalon
> > <thomas@monjalon.net>; ferruh.yigit@intel.com
> > Cc: dev@dpdk.org; Asaf Penso <asafp@mellanox.com>
> > Subject: Re: [PATCH] doc: refine ethernet and VLAN flow rule items
> > 
> > On 4/23/20 9:30 PM, Dekel Peled wrote:  
> > > Specified pattern may be translated in different manner.
> > > For example the pattern "eth / ipv4" can be translated to match
> > > untagged packets only, since the pattern doesn't specify a vlan item.  
> > 
> > vlan -> VLAN  
> 
> I will change to uppercase.
> 
> >   
> > > It can also be translated to match both tagged and untagged packets,
> > > for the same reason.
> > > This patch updates the rte_flow documentation to clearly specify the
> > > required pattern to use.
> > > For example:
> > > To match tagged ipv4 packets, the pattern "eth type is 0x8100 / vlan /
> > > ipv4 / end" should be used.  
> > 
> > Isn't eth / vlan / ipv4 /end sufficient? What's the difference?
> > I guess later should allow any VLAN TPID, but it is greyish since it is HW
> > dependent.  
> 
> In the example I wanted to show explicit rule, to emphasize the importance of detailed pattern structure.
> 
> >   
> > > To match untagged ipv4 packets, the pattern "eth type is 0x0800 /
> > > ipv4 / end" should be used.  
> > 
> > What about eth / ipv4 / end?
> > Does usage of ipv4 assume that EtherType is 0x0800?  
> 
> Same as above.
> 
> >   
> > > To match both tagged and untagged packets, the pattern "eth / end"
> > > should be used.  
> > 
> > The interesting question is what should be used if I want either tagged or
> > untagged IPv4 packets. I think it worse to mention to make the picture
> > complete.  
> 
> To match any IPV4 packet, either tagged or untagged, need to apply two rules.
> One for tagged packets and the other for untagged packets.
> I will add this example as well.
> 
> >   
> > > Signed-off-by: Dekel Peled <dekelp@mellanox.com>

All this reminds me that "code is the best documentation" and there
is no working code that does a complete software implementation of the
rte_flow engine. This means the actual interpretation of what the rte_flow
means is left to documentation and hardware vendors choices in implementation.


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

* Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
  2020-04-26 17:02     ` Stephen Hemminger
@ 2020-04-27  6:52       ` Ori Kam
  0 siblings, 0 replies; 10+ messages in thread
From: Ori Kam @ 2020-04-27  6:52 UTC (permalink / raw)
  To: Stephen Hemminger, Dekel Peled
  Cc: Andrew Rybchenko, john.mcnamara, marko.kovacevic,
	Thomas Monjalon, ferruh.yigit, dev, Asaf Penso

Hi Stephen,

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, April 26, 2020 8:02 PM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: Andrew Rybchenko <arybchenko@solarflare.com>; Ori Kam
> <orika@mellanox.com>; john.mcnamara@intel.com;
> marko.kovacevic@intel.com; Thomas Monjalon <thomas@monjalon.net>;
> ferruh.yigit@intel.com; dev@dpdk.org; Asaf Penso <asafp@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items
> 
> On Sun, 26 Apr 2020 09:18:54 +0000
> Dekel Peled <dekelp@mellanox.com> wrote:
> 
> > Thanks, PSB.
> >
> > > -----Original Message-----
> > > From: Andrew Rybchenko <arybchenko@solarflare.com>
> > > Sent: Saturday, April 25, 2020 5:00 PM
> > > To: Dekel Peled <dekelp@mellanox.com>; Ori Kam <orika@mellanox.com>;
> > > john.mcnamara@intel.com; marko.kovacevic@intel.com; Thomas Monjalon
> > > <thomas@monjalon.net>; ferruh.yigit@intel.com
> > > Cc: dev@dpdk.org; Asaf Penso <asafp@mellanox.com>
> > > Subject: Re: [PATCH] doc: refine ethernet and VLAN flow rule items
> > >
> > > On 4/23/20 9:30 PM, Dekel Peled wrote:
> > > > Specified pattern may be translated in different manner.
> > > > For example the pattern "eth / ipv4" can be translated to match
> > > > untagged packets only, since the pattern doesn't specify a vlan item.
> > >
> > > vlan -> VLAN
> >
> > I will change to uppercase.
> >
> > >
> > > > It can also be translated to match both tagged and untagged packets,
> > > > for the same reason.
> > > > This patch updates the rte_flow documentation to clearly specify the
> > > > required pattern to use.
> > > > For example:
> > > > To match tagged ipv4 packets, the pattern "eth type is 0x8100 / vlan /
> > > > ipv4 / end" should be used.
> > >
> > > Isn't eth / vlan / ipv4 /end sufficient? What's the difference?
> > > I guess later should allow any VLAN TPID, but it is greyish since it is HW
> > > dependent.
> >
> > In the example I wanted to show explicit rule, to emphasize the importance of
> detailed pattern structure.
> >
> > >
> > > > To match untagged ipv4 packets, the pattern "eth type is 0x0800 /
> > > > ipv4 / end" should be used.
> > >
> > > What about eth / ipv4 / end?
> > > Does usage of ipv4 assume that EtherType is 0x0800?
> >
> > Same as above.
> >
> > >
> > > > To match both tagged and untagged packets, the pattern "eth / end"
> > > > should be used.
> > >
> > > The interesting question is what should be used if I want either tagged or
> > > untagged IPv4 packets. I think it worse to mention to make the picture
> > > complete.
> >
> > To match any IPV4 packet, either tagged or untagged, need to apply two
> rules.
> > One for tagged packets and the other for untagged packets.
> > I will add this example as well.
> >
> > >
> > > > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> 
> All this reminds me that "code is the best documentation" and there
> is no working code that does a complete software implementation of the
> rte_flow engine. This means the actual interpretation of what the rte_flow
> means is left to documentation and hardware vendors choices in
> implementation.

I agree with you, that is why I think this patch is important. 

Best,
Ori

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

* [dpdk-dev] [PATCH v2] doc: refine ethernet and VLAN flow rule items
  2020-04-23 18:30 [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items Dekel Peled
  2020-04-25 14:00 ` Andrew Rybchenko
@ 2020-05-03  7:17 ` Dekel Peled
  2020-05-03  9:56   ` Andrew Rybchenko
  2020-05-05 16:51   ` Ferruh Yigit
  1 sibling, 2 replies; 10+ messages in thread
From: Dekel Peled @ 2020-05-03  7:17 UTC (permalink / raw)
  To: orika, john.mcnamara, marko.kovacevic, thomas, ferruh.yigit, arybchenko
  Cc: dev, asafp

Specified pattern may be translated in different manner.
For example the pattern "eth / ipv4" can be translated to match
untagged packets only, since the pattern doesn't specify a VLAN item.
It can also be translated to match both tagged and untagged packets,
for the same reason.
This patch updates the rte_flow documentation to clearly specify the
required pattern to use.
For example:
To match tagged ipv4 packets, the pattern "eth / vlan / ipv4 / end"
should be used.
To match untagged ipv4 packets, the pattern "eth / ipv4 / end"
should be used.
To match all IPV4 packets, both tagged and untagged, need to apply
two rules with the patterns above.
To match both tagged and untagged packets of any type, the pattern
"eth / end" should be used.

Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
 doc/guides/prog_guide/rte_flow.rst | 7 +++++++
 lib/librte_ethdev/rte_flow.h       | 8 ++++++++
 2 files changed, 15 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 15c7b80..d5dd18c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -905,6 +905,11 @@ so-called layer 2.5 pattern items such as ``RTE_FLOW_ITEM_TYPE_VLAN``. In
 the latter case, ``type`` refers to that of the outer header, with the inner
 EtherType/TPID provided by the subsequent pattern item. This is the same
 order as on the wire.
+If the ``type`` field contains a TPID value, then only tagged packets with the
+specified TPID will match the pattern.
+Otherwise, only untagged packets will match the pattern.
+If the ``ETH`` item is the only item in the pattern, and the ``type`` field is
+not specified, then both tagged and untagged packets will match the pattern.
 
 - ``dst``: destination MAC.
 - ``src``: source MAC.
@@ -919,6 +924,8 @@ Matches an 802.1Q/ad VLAN tag.
 The corresponding standard outer EtherType (TPID) values are
 ``RTE_ETHER_TYPE_VLAN`` or ``RTE_ETHER_TYPE_QINQ``. It can be overridden by the
 preceding pattern item.
+If a ``VLAN`` item is present in the pattern, then only tagged packets will
+match the pattern.
 
 - ``tci``: tag control information.
 - ``inner_type``: inner EtherType or TPID.
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 1fb94f3..b0e4199 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -710,6 +710,12 @@ struct rte_flow_item_raw {
  * the latter case, @p type refers to that of the outer header, with the
  * inner EtherType/TPID provided by the subsequent pattern item. This is the
  * same order as on the wire.
+ * If the @p type field contains a TPID value, then only tagged packets with the
+ * specified TPID will match the pattern.
+ * Otherwise, only untagged packets will match the pattern.
+ * If the @p ETH item is the only item in the pattern, and the @p type field
+ * is not specified, then both tagged and untagged packets will match the
+ * pattern.
  */
 struct rte_flow_item_eth {
 	struct rte_ether_addr dst; /**< Destination MAC. */
@@ -734,6 +740,8 @@ struct rte_flow_item_eth {
  * The corresponding standard outer EtherType (TPID) values are
  * RTE_ETHER_TYPE_VLAN or RTE_ETHER_TYPE_QINQ. It can be overridden by
  * the preceding pattern item.
+ * If a @p VLAN item is present in the pattern, then only tagged packets will
+ * match the pattern.
  */
 struct rte_flow_item_vlan {
 	rte_be16_t tci; /**< Tag control information. */
-- 
1.8.3.1


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

* Re: [dpdk-dev] [PATCH v2] doc: refine ethernet and VLAN flow rule items
  2020-05-03  7:17 ` [dpdk-dev] [PATCH v2] " Dekel Peled
@ 2020-05-03  9:56   ` Andrew Rybchenko
  2020-05-03 14:57     ` Ori Kam
  2020-05-05 16:51   ` Ferruh Yigit
  1 sibling, 1 reply; 10+ messages in thread
From: Andrew Rybchenko @ 2020-05-03  9:56 UTC (permalink / raw)
  To: Dekel Peled, orika, john.mcnamara, marko.kovacevic, thomas, ferruh.yigit
  Cc: dev, asafp

On 5/3/20 10:17 AM, Dekel Peled wrote:
> Specified pattern may be translated in different manner.
> For example the pattern "eth / ipv4" can be translated to match
> untagged packets only, since the pattern doesn't specify a VLAN item.
> It can also be translated to match both tagged and untagged packets,
> for the same reason.
> This patch updates the rte_flow documentation to clearly specify the
> required pattern to use.
> For example:
> To match tagged ipv4 packets, the pattern "eth / vlan / ipv4 / end"
> should be used.
> To match untagged ipv4 packets, the pattern "eth / ipv4 / end"
> should be used.
> To match all IPV4 packets, both tagged and untagged, need to apply
> two rules with the patterns above.
> To match both tagged and untagged packets of any type, the pattern
> "eth / end" should be used.
> 
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>

Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>


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

* Re: [dpdk-dev] [PATCH v2] doc: refine ethernet and VLAN flow rule items
  2020-05-03  9:56   ` Andrew Rybchenko
@ 2020-05-03 14:57     ` Ori Kam
  2020-05-07 14:18       ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Ori Kam @ 2020-05-03 14:57 UTC (permalink / raw)
  To: Andrew Rybchenko, Dekel Peled, john.mcnamara, marko.kovacevic,
	Thomas Monjalon, ferruh.yigit
  Cc: dev, Asaf Penso



> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> 
> On 5/3/20 10:17 AM, Dekel Peled wrote:
> > Specified pattern may be translated in different manner.
> > For example the pattern "eth / ipv4" can be translated to match
> > untagged packets only, since the pattern doesn't specify a VLAN item.
> > It can also be translated to match both tagged and untagged packets,
> > for the same reason.
> > This patch updates the rte_flow documentation to clearly specify the
> > required pattern to use.
> > For example:
> > To match tagged ipv4 packets, the pattern "eth / vlan / ipv4 / end"
> > should be used.
> > To match untagged ipv4 packets, the pattern "eth / ipv4 / end"
> > should be used.
> > To match all IPV4 packets, both tagged and untagged, need to apply
> > two rules with the patterns above.
> > To match both tagged and untagged packets of any type, the pattern
> > "eth / end" should be used.
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> 
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Ori Kam <orika@mellanox.com>
Thanks,
Ori


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

* Re: [dpdk-dev] [PATCH v2] doc: refine ethernet and VLAN flow rule items
  2020-05-03  7:17 ` [dpdk-dev] [PATCH v2] " Dekel Peled
  2020-05-03  9:56   ` Andrew Rybchenko
@ 2020-05-05 16:51   ` Ferruh Yigit
  1 sibling, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2020-05-05 16:51 UTC (permalink / raw)
  To: Dekel Peled, orika, john.mcnamara, marko.kovacevic, thomas, arybchenko
  Cc: dev, asafp, Ajit Khaparde, Somnath Kotur, Keith Wiles,
	Beilei Xing, Jeff Guo, Gaetan Rivet, Rosen Xu, Andrew Rybchenko,
	Wei Hu (Xavier), Min Hu (Connor),
	Yisen Zhuang, Qiming Yang, Wenzhuo Lu, Wei Zhao, Jeff Guo,
	Jingjing Wu, Beilei Xing, Jerin Jacob, Nithin Dabilpuram,
	Kiran Kumar K, John Daley, Hyong Youb Kim, Jasvinder Singh,
	Cristian Dumitrescu, Matan Azrad, Viacheslav Ovsiienko, Wei Zhao,
	Chas Williams, Hemant Agrawal, Sachin Saxena, Ziyang Xuan,
	Xiaoyun Wang, Guoyang Zhou, Rahul Lakkireddy, Rasesh Mody,
	Shahed Shaikh, Liron Himi, Shahaf Shuler

On 5/3/2020 8:17 AM, Dekel Peled wrote:
> Specified pattern may be translated in different manner.
> For example the pattern "eth / ipv4" can be translated to match
> untagged packets only, since the pattern doesn't specify a VLAN item.
> It can also be translated to match both tagged and untagged packets,
> for the same reason.
> This patch updates the rte_flow documentation to clearly specify the
> required pattern to use.
> For example:
> To match tagged ipv4 packets, the pattern "eth / vlan / ipv4 / end"
> should be used.
> To match untagged ipv4 packets, the pattern "eth / ipv4 / end"
> should be used.
> To match all IPV4 packets, both tagged and untagged, need to apply
> two rules with the patterns above.
> To match both tagged and untagged packets of any type, the pattern
> "eth / end" should be used.
> 
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>

Good to have this clarification, but also I believe we should notify the PMD
maintainers in case there are different implementations.

I have cc'ed the PMD maintainers that implemented flow_ops, to notify from the
change, planning to wait one or two more days before merging it.

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

* Re: [dpdk-dev] [PATCH v2] doc: refine ethernet and VLAN flow rule items
  2020-05-03 14:57     ` Ori Kam
@ 2020-05-07 14:18       ` Ferruh Yigit
  0 siblings, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2020-05-07 14:18 UTC (permalink / raw)
  To: Ori Kam, Andrew Rybchenko, Dekel Peled, john.mcnamara,
	marko.kovacevic, Thomas Monjalon
  Cc: dev, Asaf Penso

On 5/3/2020 3:57 PM, Ori Kam wrote:
> 
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>> On 5/3/20 10:17 AM, Dekel Peled wrote:
>>> Specified pattern may be translated in different manner.
>>> For example the pattern "eth / ipv4" can be translated to match
>>> untagged packets only, since the pattern doesn't specify a VLAN item.
>>> It can also be translated to match both tagged and untagged packets,
>>> for the same reason.
>>> This patch updates the rte_flow documentation to clearly specify the
>>> required pattern to use.
>>> For example:
>>> To match tagged ipv4 packets, the pattern "eth / vlan / ipv4 / end"
>>> should be used.
>>> To match untagged ipv4 packets, the pattern "eth / ipv4 / end"
>>> should be used.
>>> To match all IPV4 packets, both tagged and untagged, need to apply
>>> two rules with the patterns above.
>>> To match both tagged and untagged packets of any type, the pattern
>>> "eth / end" should be used.
>>>
>>> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Ori Kam <orika@mellanox.com>

Applied to dpdk-next-net/master, thanks.

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

end of thread, other threads:[~2020-05-07 14:18 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-23 18:30 [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items Dekel Peled
2020-04-25 14:00 ` Andrew Rybchenko
2020-04-26  9:18   ` Dekel Peled
2020-04-26 17:02     ` Stephen Hemminger
2020-04-27  6:52       ` Ori Kam
2020-05-03  7:17 ` [dpdk-dev] [PATCH v2] " Dekel Peled
2020-05-03  9:56   ` Andrew Rybchenko
2020-05-03 14:57     ` Ori Kam
2020-05-07 14:18       ` Ferruh Yigit
2020-05-05 16:51   ` Ferruh Yigit

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://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/ http://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