[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM0EoMmL24LxsJ1VOYHuxA=X1uoH+DRhJ5Yvq-h0oPK4mO=zmg@mail.gmail.com>
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
Powered by blists - more mailing lists