Re: [PATCH RFC net-next 0/2] net:sched: Introduce tc flower2 classifier based on PANDA parser in kernel

[Simon Horman <simon.horman@corigine.com>]

On Wed, Sep 22, 2021 at 10:28:41AM -0700, Tom Herbert wrote:
> On Wed, Sep 22, 2021 at 8:49 AM Simon Horman <simon.horman@corigine.com> wrote:
> >
> > On Wed, Sep 22, 2021 at 07:42:58AM -0700, Tom Herbert wrote:
> > > On Tue, Sep 21, 2021 at 9:46 PM Jiri Pirko <jiri@resnulli.us> wrote:
> > > >
> > > > Wed, Sep 22, 2021 at 06:38:20AM CEST, xiyou.wangcong@gmail.com wrote:
> > > > >On Thu, Sep 16, 2021 at 1:02 PM Felipe Magno de Almeida
> > > > ><felipe@sipanda.io> wrote:
> > > > >>
> > > > >> The PANDA parser, introduced in [1], addresses most of these problems
> > > > >> and introduces a developer friendly highly maintainable approach to
> > > > >> adding extensions to the parser. This RFC patch takes a known consumer
> > > > >> of flow dissector - tc flower - and  shows how it could make use of
> > > > >> the PANDA Parser by mostly cutnpaste of the flower code. The new
> > > > >> classifier is called "flower2". The control semantics of flower are
> > > > >> maintained but the flow dissector parser is replaced with a PANDA
> > > > >> Parser. The iproute2 patch is sent separately - but you'll notice
> > > > >> other than replacing the user space tc commands with "flower2"  the
> > > > >> syntax is exactly the same. To illustrate the flexibility of PANDA we
> > > > >> show a simple use case of the issues described in [2] when flower
> > > > >> consumes PANDA. The PANDA Parser is part of the PANDA programming
> > > > >> model for network datapaths, this is described in
> > > > >> https://github.com/panda-net/panda.
> > > > >
> > > > >My only concern is that is there any way to reuse flower code instead
> > > > >of duplicating most of them? Especially when you specifically mentioned
> > > > >flower2 has the same user-space syntax as flower, this makes code
> > > > >reusing more reasonable.
> > > >
> > > > Exactly. I believe it is wrong to introduce new classifier which would
> > > > basically behave exacly the same as flower, only has different parser
> > > > implementation under the hood.
> > > >
> > > > Could you please explore the possibility to replace flow_dissector by
> > > > your dissector optionally at first (kernel config for example)? And I'm
> > > > not talking only about flower, but about the rest of the flow_dissector
> > > > users too.
> >
> > +1
> >
> > > Hi Jiri,
> > >
> > > Yes, the intent is to replace flow dissector with a parser that is
> > > more extensible, more manageable and can be accelerated in hardware
> > > (good luck trying to HW accelerate flow dissector as is ;-) ). I did a
> > > presentation on this topic at the last Netdev conf:
> > > https://www.youtube.com/watch?v=zVnmVDSEoXc. FIrst introducing this
> > > with a kernel config is a good idea.
> >
> > Can we drop hyperbole? There are several examples of hardware that
> > offload (a subset of) flower. That the current kernel implementation has
> > the properties you describe is pretty much irrelevant for current hw
> > offload use-cases.
> 
> Simon,
> 
> "current hw offload use-cases" is the problem; these models offer no
> extensibility. For instance, if a new protocol appears or a user wants
> to support their own custom protocol in things like tc-flower there is
> no feasible way to do this. Unfortunately, as of today it seems, we
> are still bound by the marketing department at hardware vendors that
> pick and choose the protocols that they think their customers want and
> are willing to invest in-- we need to get past this once and for all!
> IMO, what we need is a common way to extend the kernel, tc, and other
> applications for new protocols and features, but also be able to apply
> that method to extend to the hardware which is _offloading_ kernel
> functionality which in this case is flow dissector. The technology is
> there to do this as programmable NICs for instance are the rage, but
> we do need to create common APIs to be able to do that. Note this
> isn't just tc, but a whole space of features; for instance, XDP hints
> is nice idea for the NIC to provide information about protocols in a
> packet, but unless/until there is a way to program the device to pull
> out arbitrary information that the user cares about like something
> from their custom protocol, then it's very limited utility...

... the NIC could run a BPF program if its programmable to that extent.

But ok, I accept your point that it would be good to facilitate
more flexible use in both sw and hw.