Re: [RFC]: raw packet filtering via tc-flower

[Ahmed Zaki <ahmed.zaki@intel.com>]

On 2024-02-23 6:44 a.m., Edward Cree wrote:
> On 23/02/2024 13:32, Jamal Hadi Salim wrote:
>> u32 has a DSL that deals with parsing as well, which includes dealing
>> with variable packet offsets etc. That is a necessary ingredient if
>> you want to do pragmatic parsing (example how do you point to TCP
>> ports if the IP header has options etc).
> 
> My understanding (Ahmed can correct me) is that the proposed raw
>   filtering here would not support variable packet offsets at all.
> That is precisely why I consider it a narrow hack for specialised
>   use-cases and thus oppose its addition to cls_flower.


Intel's DDP (NVM) comes with default parser tables that contain all the 
supported protocol definitions. In order to use RSS or flow director on 
any of these protocol/field that is not defined in ethtool/tc, we 
usually need to submit patches for kernel, PF and even virtchannel and 
vf drivers if we want support on the VF.

While Intel's hardware supports programming the parser IP stage (and 
that would allow mixed protocol field + binary matching/arbitrary 
offset), for now we want to support something like DPDK's raw filtering:

https://doc.dpdk.org/dts/test_plans/iavf_fdir_protocol_agnostic_flow_test_plan.html#test-case-1-vf-fdir-mac-ipv4-udp


What we had in mind is offloading based on exclusive binary matching, 
not mixed protocol field + binary matching. Also, as in my original 
example, may be restrict the protocol to 802_3, so all parsing starts at 
MAC hdr which would make the offset calculations much easier.

Please advice what is the best way forward, flower vs u32, new filter, 
..etc.

Thanks
Ahmed, Sridhar, Amritha