Re: [dpdk-dev] FW: Issues with ixgbe and rte_flow

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

Hi Wenzhuo,

On Mon, Mar 13, 2017 at 02:33:52AM +0000, Lu, Wenzhuo wrote:
[...]
> > > It's a good suggestion.  I remember we have some discussion about how
> > > to feedback the error to the APP. I think the reason why we don't make
> > > it too complex because it's the first step of generic API.  Now we see
> > > some feedback from the users, we can keep optimizing it :)
> > 
> > Right. Note ixgbe could append several messages to rte_flow_error.message if
> > necessary as in such cases. Storage for the message is provided by the PMD and
> > can be const, static or dynamic.
> > 
> > However I really think the best approach would be to report the most relevant
> > (first) error only.
> It's good if we can find which one is the most relevant. It sounds like introducing an AI to judge which kind of the filter is the best choice.
> And considering some filters may have overlap, like n-tuple and flow director.  So maybe the first one is the only option here :)

OK, I also think it's better that way. 

> > > And about the tpid, ethertype. I have a thought that why we need it as it's
> > duplicate with the item type. I think the initial design is just following the IEEE
> > spec to define the structures so we will not miss anything. But why not do some
> > optimization. For VLAN the tpid must be 0x8100, for IPv4, the ethertype must be
> > 0x0800. So why bothering let APP provide them and driver check them? Seems
> > we can just remove these fields from the structures, it can make things simpler.
> > >
> > > Adrien, as you're the maintainer of rte_flow, any thought about these ideas?
> > Thanks.
> > 
> > Basically I think we must give users the flexibility to provide nonstandard TPIDs
> > as well (there's apparently already a few), so we can't just leave it out entirely.
> Agree that TPID or something else like that can be changed. But my point is when using the filter, users don't care about the value of TPID, they only care about the vlan packets should be filtered. The type already tells the driver that. No matter we use the well-known or self-defined TPID, it's duplicate of vlan type.

You're right about the usefulness of specifying TPID in most cases, however
because the pattern is not arranged in the same order as the packet, users
do not know what EtherType they should specify inside struct
rte_flow_item_eth if they want to provide one, which I think will haunt us
for a long time (Nicolas' feedback gave me this impression.)

I'm now convinced modifying rte_flow_eth_vlan could make this much clearer
and intend to update the API accordingly. So far affected PMDs would be
i40e, ixgbe, mlx4, mlx5, sfc and tap.

I'll reply to the other thread about that.

-- 
Adrien Mazarguil
6WIND