* [RFC] ethtool: raw packet filtering
@ 2023-12-05 18:23 Ahmed Zaki
2023-12-06 16:16 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Ahmed Zaki @ 2023-12-05 18:23 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, Jakub Kicinski, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethtool: raw packet filtering
2023-12-05 18:23 [RFC] ethtool: raw packet filtering Ahmed Zaki
@ 2023-12-06 16:16 ` Jakub Kicinski
2023-12-06 22:47 ` Ahmed Zaki
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Kicinski @ 2023-12-06 16:16 UTC (permalink / raw)
To: Ahmed Zaki
Cc: netdev, davem, edumazet, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethtool: raw packet filtering
2023-12-06 16:16 ` Jakub Kicinski
@ 2023-12-06 22:47 ` Ahmed Zaki
2023-12-07 2:25 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Ahmed Zaki @ 2023-12-06 22:47 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, edumazet, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethtool: raw packet filtering
2023-12-06 22:47 ` Ahmed Zaki
@ 2023-12-07 2:25 ` Jakub Kicinski
2023-12-11 23:34 ` Ahmed Zaki
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Kicinski @ 2023-12-07 2:25 UTC (permalink / raw)
To: Ahmed Zaki
Cc: netdev, davem, edumazet, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethtool: raw packet filtering
2023-12-07 2:25 ` Jakub Kicinski
@ 2023-12-11 23:34 ` Ahmed Zaki
2023-12-12 1:50 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Ahmed Zaki @ 2023-12-11 23:34 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, edumazet, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethtool: raw packet filtering
2023-12-11 23:34 ` Ahmed Zaki
@ 2023-12-12 1:50 ` Jakub Kicinski
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Kicinski @ 2023-12-12 1:50 UTC (permalink / raw)
To: Ahmed Zaki
Cc: netdev, davem, edumazet, pabeni, mkubecek, Chittim, Madhu,
Samudrala, Sridhar
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-12-12 1:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-05 18:23 [RFC] ethtool: raw packet filtering Ahmed Zaki
2023-12-06 16:16 ` Jakub Kicinski
2023-12-06 22:47 ` Ahmed Zaki
2023-12-07 2:25 ` Jakub Kicinski
2023-12-11 23:34 ` Ahmed Zaki
2023-12-12 1:50 ` Jakub Kicinski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).