Message-ID: <CAAFAkD9Sh5jbp4qkzxuS+J3PGdtN-Kc2HdP8CDqweY36extSdA@mail.gmail.com>
Date:   Mon, 30 Jan 2023 14:02:04 -0500
From:   Jamal Hadi Salim <hadi@...atatu.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        John Fastabend <john.fastabend@...il.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        kernel@...atatu.com, deb.chatterjee@...el.com,
        anjali.singhai@...el.com, namrata.limaye@...el.com,
        khalidm@...dia.com, tom@...anda.io, pratyush@...anda.io,
        xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, vladbu@...dia.com, simon.horman@...igine.com,
        stefanc@...vell.com, seong.kim@....com, mattyk@...dia.com,
        dan.daly@...el.com, john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

On Mon, Jan 30, 2023 at 12:04 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Jamal Hadi Salim <jhs@...atatu.com> writes:
>
> > So i dont have to respond to each email individually, I will respond
> > here in no particular order. First let me provide some context, if
> > that was already clear please skip it. Hopefully providing the context
> > will help us to focus otherwise that bikeshed's color and shape will
> > take forever to settle on.
> >
> > __Context__
> >
> > I hope we all agree that when you have 2x100G NIC (and i have seen
> > people asking for 2x800G NICs) no XDP or DPDK is going to save you. To
> > visualize: one 25G port is 35Mpps unidirectional. So "software stack"
> > is not the answer. You need to offload.
>
> I'm not disputing the need to offload, and I'm personally delighted that
> P4 is breaking open the vendor black boxes to provide a standardised
> interface for this.
>
> However, while it's true that software can't keep up at the high end,
> not everything runs at the high end, and today's high end is tomorrow's
> mid end, in which XDP can very much play a role. So being able to move
> smoothly between the two, and even implement functions that split
> processing between them, is an essential feature of a programmable
> networking path in Linux. Which is why I'm objecting to implementing the
> P4 bits as something that's hanging off the side of the stack in its own
> thing and is not integrated with the rest of the stack. You were touting
> this as a feature ("being self-contained"). I consider it a bug.
>
> > Scriptability is not a new idea in TC (see u32 and pedit and others in
> > TC).
>
> u32 is notoriously hard to use. The others are neat, but obviously
> limited to particular use cases.

Despite my love for u32, I admit its user interface is cryptic. I just
wanted to point out to existing samples of scriptable and offloadable
TC objects.

> Do you actually expect anyone to use P4
> by manually entering TC commands to build a pipeline? I really find that
> hard to believe...

You dont have to manually hand code anything - its the compilers job.
But of course for simple P4 programs, yes i think you can handcode
something if you understand the templating syntax.

> > IOW, we are reusing and plugging into a proven and deployed mechanism
> > with a built-in policy driven, transparent symbiosis between hardware
> > offload and software that has matured over time. You can take a
> > pipeline or a table or actions and split them between hardware and
> > software transparently, etc.
>
> That's a control plane feature though, it's not an argument for adding
> another interpreter to the kernel.

I am not sure what you mean by control, but what i described is kernel built in.
Of course i could do more complex things from user space (if that is
what you mean as control).

> > This hammer already meets our goals.
>
> That 60k+ line patch submission of yours says otherwise...

This is pretty much covered in the cover letter and a few responses in
the thread since.

> > It's about using the appropriate tool for the right problem. We are
> > not going to rewrite that infra in rust or ebpf just because.
>
> "The right tool for the job" also means something that integrates well
> with the wider ecosystem. For better or worse, in the kernel that
> ecosystem (of datapath programmability) is BPF-based. Dismissing request
> to integrate with that as, essentially, empty fanboyism, comes across as
> incredibly arrogant.
> > Toke, I labelled that one option as IMpossible as a parody - it is
> > what the vendors are saying today and my play on words is "even
> > impossible says IM possible".
>
> Side note: I think it would be helpful if you dropped all the sarcasm
> and snide remarks when communicating this stuff in writing, especially
> to a new audience. It just confuses things, and doesn't exactly help
> with the perception of arrogance either...

I apologize if i offended you - you quoted a slide i did and I was
describing what that slide was supposed to relay.

cheers,
jamal

> -Toke
>

Powered by blists - more mailing lists