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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240226070353.79154709@kernel.org>
Date: Mon, 26 Feb 2024 07:03:53 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Ahmed Zaki <ahmed.zaki@...el.com>
Cc: Edward Cree <ecree.xilinx@...il.com>, Jamal Hadi Salim
 <jhs@...atatu.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, 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.

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