All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <hadi@mojatatu.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>,
	John Fastabend <john.fastabend@gmail.com>,
	Willem de Bruijn <willemb@google.com>,
	Stanislav Fomichev <sdf@google.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 14:02:04 -0500	[thread overview]
Message-ID: <CAAFAkD9Sh5jbp4qkzxuS+J3PGdtN-Kc2HdP8CDqweY36extSdA@mail.gmail.com> (raw)
In-Reply-To: <878rhkx8bd.fsf@toke.dk>

On Mon, Jan 30, 2023 at 12:04 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> 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.

Despite my love for u32, I admit its user interface is cryptic. I just
wanted to point out to existing samples of scriptable and offloadable
TC objects.

> Do you actually expect anyone to use P4
> by manually entering TC commands to build a pipeline? I really find that
> hard to believe...

You dont have to manually hand code anything - its the compilers job.
But of course for simple P4 programs, yes i think you can handcode
something if you understand the templating syntax.

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

I am not sure what you mean by control, but what i described is kernel built in.
Of course i could do more complex things from user space (if that is
what you mean as control).

> > This hammer already meets our goals.
>
> That 60k+ line patch submission of yours says otherwise...

This is pretty much covered in the cover letter and a few responses in
the thread since.

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

I apologize if i offended you - you quoted a slide i did and I was
describing what that slide was supposed to relay.

cheers,
jamal

> -Toke
>

  reply	other threads:[~2023-01-30 19:02 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 [this message]
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=CAAFAkD9Sh5jbp4qkzxuS+J3PGdtN-Kc2HdP8CDqweY36extSdA@mail.gmail.com \
    --to=hadi@mojatatu.com \
    --cc=anjali.singhai@intel.com \
    --cc=dan.daly@intel.com \
    --cc=davem@davemloft.net \
    --cc=deb.chatterjee@intel.com \
    --cc=edumazet@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.