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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Jan 2023 15:42:10 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Jiri Pirko <jiri@...nulli.us>,
        John Fastabend <john.fastabend@...il.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jamal Hadi Salim <hadi@...atatu.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

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?

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

     Andrew