Re: [PATCH net-next RFC 00/20] Introducing P4TC

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Jamal Hadi Salim <jhs@mojatatu.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. Do you actually expect anyone to use P4
by manually entering TC commands to build a pipeline? I really find that
hard to believe...

> 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.

> This hammer already meets our goals.

That 60k+ line patch submission of yours says otherwise...

> 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...

-Toke