[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM0EoM=8gqdZXt02v0jmHTqnjru4Ocv6ddjzjBXhU6eFoN50ng@mail.gmail.com>
Date: Tue, 11 Jun 2024 15:13:39 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, deb.chatterjee@...el.com, anjali.singhai@...el.com,
namrata.limaye@...el.com, tom@...anda.io, mleitner@...hat.com,
Mahesh.Shirshyad@....com, tomasz.osinski@...el.com, jiri@...nulli.us,
xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, vladbu@...dia.com, horms@...nel.org, khalidm@...dia.com,
toke@...hat.com, victor@...atatu.com, pctammela@...atatu.com,
Vipin.Jain@....com, dan.daly@...el.com, andy.fingerhut@...il.com,
chris.sommers@...sight.com, mattyk@...dia.com, bpf@...r.kernel.org,
Jonathan Corbet <corbet@....net>, Oz Shlomo <ozsh@...dia.com>
Subject: Re: [PATCH net-next v16 00/15] Introducing P4TC (series 1)
On Tue, Jun 11, 2024 at 1:53 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 11 Jun 2024 11:53:28 -0400 Jamal Hadi Salim wrote:
> > > For me it's very much not "about P4". I don't care what DSL user prefers
> > > and whether the device the offloads targets is built by a P4 vendor.
> >
> > I think it is an important detail though.
> > You wouldnt say PSP shouldnt start small by first taking care of TLS
> > or IPSec because it is not the target.
>
> I really don't see any parallel with PSP. And it _is_ small, 4kLoC.
>
> First you complain that community is "political" and doesn't give you
> technical feedback, and then when you get technical feedback you attack
> the work of the maintainer helping you.
>
You made a proposal saying it was a "start small" approach. I
responded saying that it doesnt really cover our requirements and
pointed to a sample h/w to show why. I only used PSP to illustrate why
"start small" doesnt work for what we are targeting. I was not in any
way attacking your work.
We are not trying to cover the whole world of offloads. It is a very
specific niche -P4- which uses the existing tc model because that's
how match-action tables are offloaded today. The actions and tables
are dynamically defined by the users P4 program whereas in flower they
are hardcoded in the kernel. I dont see any other way to achieve these
goals with flower or other existing approaches. Flower for example
could be written as a single P4 program and the goal here is to
support a wider range of programs without making kernel changes.
cheers,
jamal
Powered by blists - more mailing lists