[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bef1ce9b-25f0-4466-9669-5ea0397f2582@intel.com>
Date: Wed, 6 Dec 2023 15:47:18 -0700
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
<pabeni@...hat.com>, <mkubecek@...e.cz>, "Chittim, Madhu"
<madhu.chittim@...el.com>, "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: Re: [RFC] ethtool: raw packet filtering
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
Powered by blists - more mailing lists