Re: [RFC] ethtool: raw packet filtering

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

On 2023-12-06 19:25, Jakub Kicinski wrote:
> On Wed, 6 Dec 2023 15:47:18 -0700 Ahmed Zaki wrote:
>> Sure. The main use case is to be able to filter on any standard or
>> proprietary protocol headers, tunneled or not, using the ntuple API.
>> ethtool allows this only for the basic TCP/UDP/SCTP/ah/esp and IPv4/6.
>> Filtering on any other protocol or stack of protocols will require
>> ethtool and core changes. Raw filtering on the first 512 bytes of the
>> packet will allow anyone to do such filtering without these changes.
>>
>> To be clear, I am not advocating for bypassing Kernel parsing, but there
>> are so many combinations of protocols and tunneling methods that it is
>> very hard to add them all in ethtool.
>>
>> As an example, if we want to direct flows carrying GTPU traffic
>> originating from <Inner IP> and tunneled on a given VxLan at a given
>> <Outer IP>:
>>
>> <Outer IP> : <Outer UDP> : <VXLAN VID> : <ETH> : <Inner IP> : <GTPU>
>>
>> to a specific RSS queue.
> 
> Dunno. I think it's a longer conversation. In principle - I personally
> don't mind someone extending raw matching support, others who care about
> protocol ossification and sensible parsing API might. But if you want
> 512B you would have to redo the uAPI, and adding stuff to ethtool ioctl
> has very high bar as this is a legacy interface. Moving ntuple filters
> to netlink OTOH is a different can of warms - it duplicates parts of TC
> and nft while having a _lot_ less capabilities. And performance
> (everything under rtnl). Which begs the question whether we should
> leave n-tuple filters behind completely and focus on tc / nft APIs.
> 
> So I'll be completely honest - feels like this is going to be really
> high effort / benefit ratio for the maintainers. It will be challenging
> to get it merged.

I agree on the n-tuple hurdles, but is there a tc/nft API that you have 
in mind? Not sure where are the overlaps/duplication.

I couldn't find anything that can be extended to offload RX packet 
filtering/matching. Or did you mean __create__ new APIs?