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

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]

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!