[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUq1Ez1g8nBvA8Ad@nanopsycho>
Date: Wed, 22 Sep 2021 06:46:11 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Felipe Magno de Almeida <felipe@...anda.io>,
Jamal Hadi Salim <jhs@...atatu.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
boris.sukholitko@...adcom.com, vadym.kochan@...ision.eu,
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>,
tom Herbert <tom@...anda.io>,
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
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.
Thanks!
Powered by blists - more mailing lists