eBPF to implement core functionility WAS Re: [PATCH net-next v12 00/15] Introducing P4TC (series 1)

From: Tom Herbert <tom@sipanda.io>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Jamal Hadi Salim" <jhs@mojatatu.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Singhai, Anjali" <anjali.singhai@intel.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Linux Kernel Network Developers" <netdev@vger.kernel.org>,
	"Chatterjee, Deb" <deb.chatterjee@intel.com>,
	"Limaye, Namrata" <namrata.limaye@intel.com>,
	"Marcelo Ricardo Leitner" <mleitner@redhat.com>,
	"Shirshyad, Mahesh" <Mahesh.Shirshyad@amd.com>,
	"Jain, Vipin" <Vipin.Jain@amd.com>,
	"Osinski, Tomasz" <tomasz.osinski@intel.com>,
	"Jiri Pirko" <jiri@resnulli.us>,
	"Cong Wang" <xiyou.wangcong@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Vlad Buslov" <vladbu@nvidia.com>,
	"Simon Horman" <horms@kernel.org>,
	"Khalid Manaa" <khalidm@nvidia.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Victor Nogueira" <victor@mojatatu.com>,
	"Tammela, Pedro" <pctammela@mojatatu.com>,
	"Daly, Dan" <dan.daly@intel.com>,
	"Andy Fingerhut" <andy.fingerhut@gmail.com>,
	"Sommers, Chris" <chris.sommers@keysight.com>,
	"Matty Kadosh" <mattyk@nvidia.com>, bpf <bpf@vger.kernel.org>
Subject: eBPF to implement core functionility WAS Re: [PATCH net-next v12 00/15] Introducing P4TC (series 1)
Date: Mon, 4 Mar 2024 12:58:29 -0800	[thread overview]
Message-ID: <CAOuuhY99WQbtFQhaU8HhW4_XaX6nPs2F0XVHqeDLUVqCMfsg8w@mail.gmail.com> (raw)
In-Reply-To: <20240304120747.6f34ab6e@kernel.org>

On Mon, Mar 4, 2024 at 12:07 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sun, 3 Mar 2024 08:31:11 -0800 Tom Herbert wrote:
> > Even before considering hardware offload, I think this approach
> > addresses a more fundamental problem to make the kernel programmable.
>
> I like some aspects of what you're describing, but my understanding
> is that it'd be a noticeable shift in direction.
> I'm not sure if merging P4TC is the most effective way of taking
> a first step in that direction. (I mean that in the literal sense
> of lack of confidence, not polite way to indicate holding a conviction
> to the contrary.)

Jakub,

My comments were with regards to making the kernel offloadable by
first making it programmable. The P4TC patches are very good for
describing processing that is table driven like filtering or IPtables,
but I was thinking more of kernel datapath processing that isn't table
driven like GSO, GRO, flow dissector, and even up to revisiting TCP
offload.

Basically, I'm proposing that instead of eBPF always being side
functionality, there are cases where it could natively be used to
implement the main functionality of the kernel datapath! It is a
noticeable shift in direction, but I also think it's the logical
outcome of eBPF :-).

Tom