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

On Wed, Sep 22, 2021 at 07:42:58AM -0700, Tom Herbert wrote:

On Tue, Sep 21, 2021 at 9:46 PM Jiri Pirko [off-list ref] wrote:

quoted

Wed, Sep 22, 2021 at 06:38:20AM CEST, xiyou.wangcong@gmail.com wrote:

quoted

On Thu, Sep 16, 2021 at 1:02 PM Felipe Magno de Almeida
[off-list ref] wrote:

quoted

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.