[RFC] ethtool: raw packet filtering

[RFC] ethtool: raw packet filtering

[Ahmed Zaki]

Hello,

We are planning to send a patch series that enables raw packet filtering 
for ice and iavf. However, ethtool currently allows raw filtering on 
only 8 bytes via "user-def":

   # ethtool -N eth0 flow-type user-def N [m N] action N


We are seeking the community's opinion on how to extend the ntuple 
interface to allow for up to 512 bytes of raw packet filtering. The 
direct approach is:

   # ethtool -N eth0 flow-type raw-fltr N [m N] action N

where N would be allowed to be 512 bytes. Would that be acceptable? Any 
concerns regarding netlink or other user-space/kernel comm?

Thank you.

Re: [RFC] ethtool: raw packet filtering

[Jakub Kicinski]

On Tue, 5 Dec 2023 11:23:34 -0700 Ahmed Zaki wrote:
> We are planning to send a patch series that enables raw packet filtering 
> for ice and iavf. However, ethtool currently allows raw filtering on 
> only 8 bytes via "user-def":
> 
>    # ethtool -N eth0 flow-type user-def N [m N] action N
> 
> 
> We are seeking the community's opinion on how to extend the ntuple 
> interface to allow for up to 512 bytes of raw packet filtering. The 
> direct approach is:
> 
>    # ethtool -N eth0 flow-type raw-fltr N [m N] action N
> 
> where N would be allowed to be 512 bytes. Would that be acceptable? Any 
> concerns regarding netlink or other user-space/kernel comm?

We need more info about the use case and what this will achieve.
Asking if you can extend uAPI is like asking if you can walk in
the street. Sometimes you can sometimes you can't. All depends
on context, so start with the context, please.

Re: [RFC] ethtool: raw packet filtering

[Ahmed Zaki]

On 2023-12-06 09:16, Jakub Kicinski wrote:
> On Tue, 5 Dec 2023 11:23:34 -0700 Ahmed Zaki wrote:
>> We are planning to send a patch series that enables raw packet filtering
>> for ice and iavf. However, ethtool currently allows raw filtering on
>> only 8 bytes via "user-def":
>>
>>     # ethtool -N eth0 flow-type user-def N [m N] action N
>>
>>
>> We are seeking the community's opinion on how to extend the ntuple
>> interface to allow for up to 512 bytes of raw packet filtering. The
>> direct approach is:
>>
>>     # ethtool -N eth0 flow-type raw-fltr N [m N] action N
>>
>> where N would be allowed to be 512 bytes. Would that be acceptable? Any
>> concerns regarding netlink or other user-space/kernel comm?
> 
> We need more info about the use case and what this will achieve.
> Asking if you can extend uAPI is like asking if you can walk in
> the street. Sometimes you can sometimes you can't. All depends
> on context, so start with the context, please.

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.

BR,
Ahmed

Re: [RFC] ethtool: raw packet filtering

[Jakub Kicinski]

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.

Re: [RFC] ethtool: raw packet filtering

[Ahmed Zaki]

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?

Re: [RFC] ethtool: raw packet filtering

[Jakub Kicinski]

On Mon, 11 Dec 2023 16:34:42 -0700 Ahmed Zaki wrote:
> 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?

Look at net/sched/cls_flower.c and grep around for struct flow_rule.
struct flow_rule was supposed to be the common representation for all
flows at driver level, ethtool, TC flower, nftables. Very limited
success on the ethtool side, but grepping for it should lead you to
the other two uAPIs.