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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 27 Feb 2024 10:25:17 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Ahmed Zaki <ahmed.zaki@...el.com>, Edward Cree <ecree.xilinx@...il.com>, 
	Jiri Pirko <jiri@...nulli.us>, stephen@...workplumber.org, davem@...emloft.net, 
	edumazet@...gle.com, pabeni@...hat.com, corbet@....net, 
	xiyou.wangcong@...il.com, netdev@...r.kernel.org, 
	"Chittim, Madhu" <madhu.chittim@...el.com>, 
	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>, amritha.nambiar@...el.com, 
	Jan Sokolowski <jan.sokolowski@...el.com>
Subject: Re: [RFC]: raw packet filtering via tc-flower

On Mon, Feb 26, 2024 at 10:03 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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.
>

Yes, u32 is the most "ready". No need to patch the classifier code
(unlike flower) and the dev ops exists already (and has been used by
drivers in the past).

> 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..

P4 will open much bigger opportunities for DDP imo (but some people
would claim i am a little tiny biased ;->).

cheers,
jamal