From: Andrew Lunn <andrew@lunn.ch>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"Jiri Pirko" <jiri@resnulli.us>,
"John Fastabend" <john.fastabend@gmail.com>,
"Willem de Bruijn" <willemb@google.com>,
"Stanislav Fomichev" <sdf@google.com>,
"Jamal Hadi Salim" <hadi@mojatatu.com>,
"Jakub Kicinski" <kuba@kernel.org>,
netdev@vger.kernel.org, kernel@mojatatu.com,
deb.chatterjee@intel.com, anjali.singhai@intel.com,
namrata.limaye@intel.com, khalidm@nvidia.com, tom@sipanda.io,
pratyush@sipanda.io, xiyou.wangcong@gmail.com,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
vladbu@nvidia.com, simon.horman@corigine.com,
stefanc@marvell.com, seong.kim@amd.com, mattyk@nvidia.com,
dan.daly@intel.com, john.andy.fingerhut@intel.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC
Date: Mon, 30 Jan 2023 15:42:10 +0100 [thread overview]
Message-ID: <Y9fXQo1kmIXfs7eS@lunn.ch> (raw)
In-Reply-To: <CAM0EoM=u-VSDZAifwTiOy8vXAGX7Hwg4rdea62-kNFGsHj7ObQ@mail.gmail.com>
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
next prev parent reply other threads:[~2023-01-30 14:42 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 17:03 [PATCH net-next RFC 00/20] Introducing P4TC Jamal Hadi Salim
2023-01-26 23:30 ` Jakub Kicinski
2023-01-27 13:33 ` Jamal Hadi Salim
2023-01-27 17:18 ` Jakub Kicinski
2023-01-27 19:42 ` Jamal Hadi Salim
2023-01-28 1:34 ` Singhai, Anjali
2023-01-28 21:17 ` Tom Herbert
2023-01-29 2:09 ` Stephen Hemminger
2023-01-30 3:09 ` Singhai, Anjali
2023-01-30 17:05 ` Tom Herbert
2023-01-27 18:26 ` Jiri Pirko
2023-01-27 20:04 ` Jamal Hadi Salim
2023-01-27 22:26 ` sdf
2023-01-27 23:06 ` Tom Herbert
2023-01-28 0:47 ` Stanislav Fomichev
2023-01-28 1:32 ` Tom Herbert
2023-01-27 23:27 ` Jamal Hadi Salim
2023-01-28 0:47 ` Stanislav Fomichev
2023-01-28 13:37 ` Willem de Bruijn
2023-01-28 15:10 ` Jamal Hadi Salim
2023-01-28 15:33 ` Willem de Bruijn
2023-01-29 5:39 ` John Fastabend
2023-01-29 11:11 ` Jamal Hadi Salim
2023-01-29 11:19 ` Jamal Hadi Salim
2023-01-30 4:30 ` John Fastabend
2023-01-30 10:13 ` Jiri Pirko
2023-01-30 11:26 ` Toke Høiland-Jørgensen
2023-01-30 14:06 ` Jamal Hadi Salim
2023-01-30 14:42 ` Andrew Lunn [this message]
2023-01-30 15:31 ` Jamal Hadi Salim
2023-01-30 17:04 ` Toke Høiland-Jørgensen
2023-01-30 19:02 ` Jamal Hadi Salim
2023-01-30 20:21 ` Toke Høiland-Jørgensen
2023-01-30 21:10 ` John Fastabend
2023-01-30 21:20 ` Toke Høiland-Jørgensen
2023-01-30 22:53 ` Jamal Hadi Salim
2023-01-30 23:24 ` Singhai, Anjali
2023-01-31 0:06 ` John Fastabend
2023-01-31 0:26 ` Jamal Hadi Salim
2023-01-31 4:12 ` Jakub Kicinski
2023-01-31 10:27 ` Jamal Hadi Salim
2023-01-31 10:30 ` Jamal Hadi Salim
2023-01-31 19:10 ` Jakub Kicinski
2023-01-31 22:32 ` Jamal Hadi Salim
2023-01-31 22:36 ` Jakub Kicinski
2023-01-31 22:50 ` Jamal Hadi Salim
2023-01-30 23:32 ` John Fastabend
2023-01-31 12:17 ` Toke Høiland-Jørgensen
2023-01-31 12:37 ` Jiri Pirko
2023-01-31 14:38 ` Jiri Pirko
2023-01-31 17:01 ` Toke Høiland-Jørgensen
2023-01-31 22:23 ` Jamal Hadi Salim
2023-01-31 22:53 ` Toke Høiland-Jørgensen
2023-01-31 23:31 ` Jamal Hadi Salim
2023-02-01 18:08 ` Toke Høiland-Jørgensen
2023-02-02 18:50 ` Jamal Hadi Salim
2023-02-02 23:34 ` Tom Herbert
2023-01-30 22:41 ` Tom Herbert
2023-02-14 17:07 ` Edward Cree
2023-02-14 20:44 ` Jamal Hadi Salim
2023-02-16 20:24 ` Jamal Hadi Salim
2023-01-29 11:02 ` Jamal Hadi Salim
2023-01-29 22:14 ` Toke Høiland-Jørgensen
2023-01-28 13:41 ` Jamal Hadi Salim
2023-01-27 23:02 ` Daniel Borkmann
2023-01-27 23:57 ` Jamal Hadi Salim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9fXQo1kmIXfs7eS@lunn.ch \
--to=andrew@lunn.ch \
--cc=anjali.singhai@intel.com \
--cc=dan.daly@intel.com \
--cc=davem@davemloft.net \
--cc=deb.chatterjee@intel.com \
--cc=edumazet@google.com \
--cc=hadi@mojatatu.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.andy.fingerhut@intel.com \
--cc=john.fastabend@gmail.com \
--cc=kernel@mojatatu.com \
--cc=khalidm@nvidia.com \
--cc=kuba@kernel.org \
--cc=mattyk@nvidia.com \
--cc=namrata.limaye@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pratyush@sipanda.io \
--cc=sdf@google.com \
--cc=seong.kim@amd.com \
--cc=simon.horman@corigine.com \
--cc=stefanc@marvell.com \
--cc=toke@redhat.com \
--cc=tom@sipanda.io \
--cc=vladbu@nvidia.com \
--cc=willemb@google.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).