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

From: Jakub Kicinski <[email-masked]>
Date: Mon, 26 Feb 2024 07:03:53 -0800

On Mon, 26 Feb 2024 07:40:55 -0700 Ahmed Zaki wrote:
> 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.

I vote for u32. We can always add a new filter. But if one already
exists which fully covers the functionality we shouldn't add a new
one until we know the exact pain points, IOW have tried the existing.

If we do add a new filter, I think this should be part of the P4
classifier. With the parsing tree instantiated from the device side
and filters added by the user..