On Fri, Feb 16, 2024 at 03:58:20PM +0100, Benjamin Tissoires wrote: > > So (and this also answers your second email today) I'm thinking at: > - have multiple flags to control the timer (with dedicated timer_cb > kernel functions): > - BPF_F_TIMER_HRTIMER (default) > - BPF_F_TIMER_WORKER (no timer, just workqueue)
These two make sense, but > - BPF_F_TIMER_DELAYED_WORKER (hrtimer + workqueue, or actual > delayed_work, but that's re-implementing stuffs) This one doesn't. Unlike hrtimer the workqueue is non deterministic. Requesting a callback after a specific delay only to be randomized by the workqueue is a confusing UX to give to bpf progs. If bpf author really want to do something like that they can implement such anti-feature manually with two bpf_timers. Later we'll add a selector for WQ. At that time we'd need to decide whether to use a dedicated kthread or any of system_*_wq or WQ_BH. For now I'd only expose 'sleepable' as a guarantee in bpf api. Hence BPF_F_TIMER_SLEEPABLE is the only extra bit in flags for bpf_timer_start(). Not sure whether it's needed in bpf_timer_init() too.
