[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOuuhY8KA99mV7qBHwX79xP31tqtc9EggSNZ-=j4Z+awJUosdQ@mail.gmail.com>
Date: Wed, 22 Sep 2021 07:42:58 -0700
From: Tom Herbert <tom@...anda.io>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
Felipe Magno de Almeida <felipe@...anda.io>,
Jamal Hadi Salim <jhs@...atatu.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Boris Sukholitko <boris.sukholitko@...adcom.com>,
Vadym Kochan <vadym.kochan@...ision.eu>,
Ilya Lifshits <ilya.lifshits@...adcom.com>,
Vlad Buslov <vladbu@...dia.com>,
Ido Schimmel <idosch@...sch.org>, paulb@...dia.com,
Davide Caratti <dcaratti@...hat.com>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Amritha Nambiar <amritha.nambiar@...el.com>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Pedro Tammela <pctammela@...atatu.com>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH RFC net-next 0/2] net:sched: Introduce tc flower2
classifier based on PANDA parser in kernel
On Tue, Sep 21, 2021 at 9:46 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Wed, Sep 22, 2021 at 06:38:20AM CEST, xiyou.wangcong@...il.com wrote:
> >On Thu, Sep 16, 2021 at 1:02 PM Felipe Magno de Almeida
> ><felipe@...anda.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.
>
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.
Thanks,
Tom
> Thanks!
Powered by blists - more mailing lists