On Fri, Feb 9, 2024 at 4:42 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Benjamin Tissoires <bentiss@xxxxxxxxxx> writes: > > > [Putting this as a RFC because I'm pretty sure I'm not doing the things > > correctly at the BPF level.] > > [Also using bpf-next as the base tree as there will be conflicting > > changes otherwise] > > > > Ideally I'd like to have something similar to bpf_timers, but not > > in soft IRQ context. So I'm emulating this with a sleepable > > bpf_tail_call() (see "HID: bpf: allow to defer work in a delayed > > workqueue"). > > Why implement a new mechanism? Sounds like what you need is essentially > the bpf_timer functionality, just running in a different context, right? Heh, that's exactly why I put in a RFC :) So yes, the bpf_timer approach is cleaner, but I need it in a workqueue, as a hrtimer in a softIRQ would prevent me to kzalloc and wait for the device. > So why not just add a flag to the timer setup that controls the callback > context? I've been toying with something similar for restarting XDP TX > for my queueing patch series (though I'm not sure if this will actually > end up being needed in the end): > > https://git.kernel.org/pub/scm/linux/kernel/git/toke/linux.git/commit/?h=xdp-queueing-08&id=54bc201a358d1ac6ebfe900099315bbd0a76e862 > Oh, nice. Good idea. But would it be OK to have a "timer-like" where it actually defers the job in a workqueue instead of using an hrtimer? I thought I would have to rewrite the entire bpf_timer approach without the softIRQ, but if I can just add a new flag, that will make things way simpler for me. This however raises another issue if I were to use the bpf_timers: now the HID-BPF kfuncs will not be available as they are only available to tracing prog types. And when I tried to call them from a bpf_timer (in softIRQ) they were not available. Cheers, Benjamin
