On Sun, 26 Apr 2020 09:18:54 +0000 Dekel Peled <dek...@mellanox.com> wrote:
> Thanks, PSB. > > > -----Original Message----- > > From: Andrew Rybchenko <arybche...@solarflare.com> > > Sent: Saturday, April 25, 2020 5:00 PM > > To: Dekel Peled <dek...@mellanox.com>; Ori Kam <or...@mellanox.com>; > > john.mcnam...@intel.com; marko.kovace...@intel.com; Thomas Monjalon > > <tho...@monjalon.net>; ferruh.yi...@intel.com > > Cc: dev@dpdk.org; Asaf Penso <as...@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 <dek...@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.
