From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jamal Hadi Salim <hadi@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>, 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: Fri, 27 Jan 2023 18:57:34 -0500 [thread overview]
Message-ID: <CAM0EoMnxXi+LpbLGhW3L60ehw6PwD43U+DVAGbCahaQCbUQN4w@mail.gmail.com> (raw)
In-Reply-To: <b47d1950-add0-6449-4160-d5e2f7a8d7f7@iogearbox.net>
On Fri, Jan 27, 2023 at 6:02 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 1/27/23 9:04 PM, Jamal Hadi Salim wrote:
> > On Fri, Jan 27, 2023 at 1:26 PM Jiri Pirko <jiri@resnulli.us> wrote:
> >> Fri, Jan 27, 2023 at 12:30:22AM CET, kuba@kernel.org wrote:
> >>> On Tue, 24 Jan 2023 12:03:46 -0500 Jamal Hadi Salim wrote:
> >>>> There have been many discussions and meetings since about 2015 in regards to
> >>>> P4 over TC and now that the market has chosen P4 as the datapath specification
> >>>> lingua franca
> >>>
> >>> Which market?
> >>>
[..]
> >
> > Our rule in TC is: _if you want to offload using TC you must have a
> > s/w equivalent_.
> > We enforced this rule multiple times (as you know).
> > P4TC has a sw equivalent to whatever the hardware would do. We are pushing that
> > first. Regardless, it has value on its own merit:
> > I can run P4 equivalent in s/w in a scriptable (as in no compilation
> > in the same spirit as u32 and pedit),
>
> `62001 insertions(+), 45 deletions(-)` and more to come for a software
> datapath which in the end no-one will use (assuming you'll have the hw
> offloads) is a pretty heavy lift..
I am not sure i fully parsed what you said - but the sw stands on its own
merit. The consumption of P4 specification is one - but ability to define
arbitrary pipelines without changing the kernel code (u32/pedit like, etc) is
of value.
Note (in case i misunderstood what you are saying):
As mentioned there is commitment to support; its clean standalone and
can be compiled out
and even when compiled in has no effect on the rest of the code performance
or otherwise.
> imo the layer of abstraction is wrong
> here as Stan hinted. What if tomorrow P4 programming language is not the
> 'lingua franca' anymore and something else comes along? Then all of it is
> still baked into uapi instead of having a generic/versatile intermediate
> later.
Match-action pipeline as an approach to defining datapaths is what we
implement here.
It is what P4 defines. I dont think P4 covers everything that is
needed under the shining sun
but a lot of effort has gone into standardizing common things. And if
there are gaps we fill them.
That is a solid, well understood way to build hardware and sw (TC has
been around all these
years implementing that paradigm). So that is the intended abstraction
being implemented.
The interface is designed to be scriptable to remove the burden of
making kernel (and btw user space
as well to iproute2) changes for new processing functions (whether in
s/w or hardware).
cheers,
jamal
prev parent reply other threads:[~2023-01-27 23:57 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
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 [this message]
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=CAM0EoMnxXi+LpbLGhW3L60ehw6PwD43U+DVAGbCahaQCbUQN4w@mail.gmail.com \
--to=jhs@mojatatu.com \
--cc=anjali.singhai@intel.com \
--cc=dan.daly@intel.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=deb.chatterjee@intel.com \
--cc=edumazet@google.com \
--cc=hadi@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.andy.fingerhut@intel.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=seong.kim@amd.com \
--cc=simon.horman@corigine.com \
--cc=stefanc@marvell.com \
--cc=tom@sipanda.io \
--cc=vladbu@nvidia.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).