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

[Le Scouarnec Nicolas <Nicolas.LeScouarnec@technicolor.com>]

Hi Adrien, 

> > > > 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.

Overall, as a user, I feel one difficulty/complexity in using the API comes from the need to
specify both the stack of protocol (in type) and at each level the "next protocol type" of the header (in spec).
Then, the PMD has to check that what I specified as the "next protocol type" is coherent with the protocol
stack before setting up the filters. Basically, for a valid filter, I should always have
rte_flow_item[1].type == rte_flow_item[0].spec.type, and  rte_flow_item[2].type == rte_flow_item[1].spec.{type,next_protocol}
 (except for L2.5 protocol as I experienced, which makes thinks confusing). Couldn't the API leverage this fact so that I don't
need to specify the ether_type, TPID, next_protocol_id, ... which are redundant with rte_flow_item.type ?

Changing this wouldn't reduce the expressiveness of the filter, as long as there is a rte_flow_item type
CustomL3OverEthernet where you can specify the ether_type expected at L2, and a CustomL4OverIP
where you can specifiy the next protocol id at L3 (IP), and if needed to support custom TPID, CustomVLANOverEthernet.
These would be used by a small minority of users, thus keeping the API simpler for users of most common protocols. 

Best regards,

-- 
Nicolas Le Scouarnec