On Mon, Mar 4, 2024 at 12:07 PM Jakub Kicinski <kuba@xxxxxxxxxx> 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
