[Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF

[Benjamin Tissoires <benjamin.tissoires@redhat.com>]

On Fri, Jun 17, 2022 at 1:16 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Benjamin,
>
> Deliberate offlist reply.

[re-adding the list as your last comment]

>
> On 6/17/22 13:04, Benjamin Tissoires wrote:
> > On Fri, Jun 17, 2022 at 12:31 PM Jan Kara <jack@suse.cz> wrote:
> >>
> >> On Fri 17-06-22 09:53:52, Jiri Kosina wrote:
> >>> On Thu, 16 Jun 2022, James Bottomley wrote:
> >>>
> >>>>> If you want a "stable ebpf program" then you submit it upstream and
> >>>>> we can make sure that it works with any internal API changes, the
> >>>>> same way we do for modules. Those with out-of-tree modules will have
> >>>>> the technical debt of changing every time a new kernel release is
> >>>>> out, and so should out-of-tree bpf programs.
> >>>>
> >>>> Assuming eBPF takes off, that would have some poor maintainer managing
> >>>> the whole of the compatibility changes for the entire eBPF ecosystem
> >>>> ... I really don't think that's scalable.
> >>>
> >>> I nevertheless still see this as the best and only option we have; that
> >>> is, have an infrastructure in the kernel tree for maintaining eBPF
> >>> programs, somehow sorted per subsystem so that it mirrors the standard
> >>> maintainership / subsystem structure proper, and have the maintainers
> >>> responsible for keeping the eBPF programs related to their subsystem in
> >>> sync with the internal changes happening in the subsystem.
> >>>
> >>> At the end of the day, it will be the subsystem maintainers themsleves
> >>> accepting the program into the tree in the first place, so it's not like
> >>> they are receiving responsibility for something they never wanted in the
> >>> first place. So we'll probably end up with subsystems with many eBPF
> >>> programs, and also subsystems with zero. Similarly to tracepoints.
> >>>
> >>> I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can
> >>> hook to just about anything).
> >>>
> >>> Any other option seems to lead to having eBPF programs sprinkled all over
> >>> the internet that depend on particular kernel version / API, leading to
> >>> nothing else than unhappy users, because "I downloaded it, it didn't work,
> >>> Linux sucks".
> >>
> >> OK, but if we keep eBPF programs this closely coupled to the kernel, then
> >> what is the advantage of using eBPF, say for HID as was discussed earlier
> >> in this thread, compared to just making sure HID has appropriate hooks and
> >> the handling of the device quirks is done in normal C code (kernel module)
> >> attached to these hooks?
> >
> > [sorry some of my messages are kept in the moderation queue]
> >
> > This is something I tried to explain in my talk at Kernel Recipes 2
> > weeks ago [1].
> >
> > Basically, for regular users, it will be simpler for them to test patches:
> > A developer patches the device through a bpf program, compiles it and
> > sends to the user the source and the bytecode. The user just has to
> > drop the bytecode in the file system and a udev rule automatically
> > loads it without having to reboot the current kernel, making testing
> > way faster and simpler for users.
> >
> > Then developers take the burden of upstreaming the bpf program through
> > the usual email submission.
> >
> > This way users are testing the actual code that is upstreamed without
> > too much hurdle.
> >
> > IMO those kinds of fixes should be in-tree because they are actual fixes.
> >
> >
> >>
> >> Because frankly for me the main value of eBPF over patching and recompiling
> >> the kernel is that I can tweak the eBPF code exactly to my needs and load
> >> it to the kernel without needing to reboot, over time it is less work than
> >> maintaining a source code patch out of tree, and usually it is a hacky
> >> tweak I use for some debugging so merging it upstream does not make sense.
> >>
> >
> > And that's also why I want to give *some* guarantees that the eBPF
> > hooks I am putting in HID are somewhat stable. Or at least I won't
> > break everything at each release and look carefully when there is a
> > change in the API.
> >
> > But these guarantees are just *my* constraints I put on *my*
> > subsystem. I have reasons to believe I can ensure that, so I will.
> >
> > But I am not saying any internal HID function will have ABI
> > guarantees. Only the few hooks I am explicitly documenting as such.
> >
> > So the idea is that your debugging program can live in your own tree,
> > without being submitted, but this is just a contract between myself as
> > a subsystem maintainer and you, not the entire eBPF or ftrace
> > community.
> >
> > I made this so I can put any fancy new kernel API out in eBPF
> > programs, that would be handled by the actual user of that kernel API.
>
> I think you need to clarify this, to me it now reads that you want
> to use eBPF to implement new APIs, where as what you mean is that
> you want to avoid the need to add new APIs like e.g. sysfs knobs
> or kernel-module-parameters, right ?

Yes. Exactly. It's not about regular and standard API. It's a device
specific property/feature that is usually handled through module
parameters or custom sysfs entries that have only one single user.

>
> > If a user wants to set some fancy feature on a particular device,
> > instead of having a kernel parameter that no one will ever use besides
> > that program that may be short-lived, we can then load that
> > functionality with the eBPF program.
>
> I think you need to clarify here that you mean changing some settings
> on the device through e.g. a HID feature report which would require
> a sysfs-attribute or kernel-module-parameters without ePBF and you want
> to avoid adding more and more sysfs-attributes / kernel-module-parameters?

Yep yep :)

>
> At least I think this is what you are trying to say, and I think that
> without some clarification this is not what most kernel-devs will
> understand here.

Thanks for saying it better than I do :)

>
> Feel free to copy/paste from this reply to use my attemps at clarifying
> things, or just reply to this with the list added back to the Cc :)

And done through the lazy option, just forward to the list :)

Cheers,
Benjamin

>
> Regards,
>
> Hans
>
>
>
> > Or if a user is only interested in a particular event in a report for
> > a device (with the custom protocols some gaming devices are enjoying),
> > then that user can load a BPF program and keep it outside of the tree
> > because the program doesn't make sense without the userspace
> > component.
> >
> > I hope it clarifies a little bit now. For HID at least.
> >
> > Cheers,
> > Benjamin
> >
> > [1] https://kernel-recipes.org/en/2022/talks/hid-bpf/ and
> > https://www.youtube.com/watch?v=nhJqaZT94z0&t=14923s
> >
> > _______________________________________________
> > Ksummit-discuss mailing list
> > Ksummit-discuss@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> >
>