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

[Jamal Hadi Salim <jhs@mojatatu.com>]

On Mon, Jan 30, 2023 at 9:42 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> Hi Jamal
>
> I'm mostly sat watching and eating popcorn, and i have little
> knowledge in the area.
>
> > Jiri, i think one of the concerns you have is that there is no way to
> > generalize the different hardware by using a single abstraction since
> > all hardware may have different architectures (eg whether using RMT vs
> > DRMT, a mesh processing xbar, TCAM, SRAM, host DRAM,  etc) which may
> > necessitate doing things like underlying table reordering, merging,
> > sorting etc. The consensus is that it is the vendor driver that is
> > responsible for “transforming” P4 abstractions into whatever your
> > hardware does.
>
> What is the complexity involved in this 'transformation'? Are we
> talking about putting a P4 'compiler' into each driver, each vendor
> having there own compiler? Performing an upcall into user space with a
> P4 blob and asking the vendor tool to give us back a blob for the
> hardware? Or is it relatively simple, a few hundred lines of code,
> simple transformations?
>

The current model is you compile the kernel vs hardware output as two
separate files. They are loaded separately
The compiler has a vendor specific backend and a P4TC one. There has
to be a authentication sync that the two are one and the same;
essentially each program/pipeline has a name and an ID and some hash
for validation. See slide #49 in the presentation at
https://netdevconf.info/0x16/session.html?Your-Network-Datapath-Will-Be-P4-Scripted
Only the vendor will be able to create something reasonable for their
specific hardware.
The issue is how to load the hardware part - the three methods were
discussed are listed in slides 50-52. The vendors seem to be in
agreement that the best option is #1.

BTW, these discussions happen in a high bandwidth medium at the moment
every two weeks here:
https://www.google.com/url?q=https://teams.microsoft.com/l/meetup-join/1.&sa=D&source=calendar&ust=1675366175958603&usg=AOvVaw1UZo8g5Ir6OcC-SRFM9PF1
It would be helpful if other folks will show up in those meetings.

> As far as i know, all offloading done so far in the network stack has
> been purely in kernel. We transform a kernel representation of
> networking state into something the hardware understands and pass it
> to the hardware. That means, except for bugs, what happens in SW
> should be the same as what happens in HW, just faster.

Exactly - that is what is refered to as "hardcoding" in slides 43-44
with what P4TC would do described in slide #45.

> But there have
> been mention of P4 extensions. Stuff that the SW P4 implementation
> cannot do, but the hardware can, and vendors appear to think such
> extensions are part of their magic sauce. How will that work? Is the
> 'compiler' supposed to recognise plain P4 equivalent of these
> extensions and replace it with those extensions?

I think the "magic sauce" angle is mostly the idea of how one would
implement foobar differently than the other vendor. If someone uses a
little ASIC and the next person uses FW to program a TCAM they may
feel they have an advantage in their hardware that the other guy
doesnt have.  At the end of the day that thing looks like a box with
input Y that produces output X. In P4 they call them "externs".  From
a P4TC backend perspective, we hope that we can allow foobar to be
implemented by multiple vendors without caring about the details of
the implementation. The vendor backend can describe it to whatever
detail it wants to its hardware.

> I suppose what i'm trying to get at, is are we going to enforce the SW
> and HW equivalence by doing the transformation in kernel, or could we
> be heading towards in userspace we take our P4 and compile it with one
> toolchain for the SW path, another toolchain for the HW path, and we
> have no guarantee that the resulting blobs actually came from the same
> sources and are supposed to be equivalent? And that then makes the SW
> path somewhat pointless?

See above - the two have to map to the same equivalence and validated as such.
It is also about providing a singular interface through the kernel as
opposed to dealing
with multiple vendor APIs.

cheers,
jamal