Re: [PATCH RFC bpf-next 0/3] Execution context callbacks

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Jul 12, 2022 at 06:42:52PM +0000, Delyan Kratunov wrote:
> 
> > but have you though of maybe initially supporting something like:
> > 
> > bpf_timer_init(&timer, map, SOME_NEW_DEFERRED_NMI_ONLY_FLAG);
> > bpf_timer_set_callback(&timer, cg);
> > bpf_timer_start(&timer, 0, 0);
> > 
> > If you init a timer with that special flag, I'm assuming you can have
> > special cases in the existing helpers to simulate the delayed work?
> 
> Potentially but I have some reservations about drawing this equivalence.

hrtimer api has various: flags. soft vs hard irq, pinned and not.
So the suggestion to treat irq_work callback as special timer flag
actually fits well.

bpf_timer_init + set_callback + start can be a static inline function
named bpf_work_submit() in bpf_helpers.h
(or some new file that will mark the beginning libc-bpf library).
Reusing struct bpf_timer and adding zero-delay callback could probably be
easier for users to learn and consume.

Separately:
+struct bpf_delayed_work {
+       __u64 :64;
+       __u64 :64;
+       __u64 :64;
+       __u64 :64;
+       __u64 :64;
+} __attribute__((aligned(8)));
is not extensible.
It would be better to add indirection to allow kernel side to grow
independently from amount of space consumed in a map value.

Can you think of a way to make irq_work/sleepable callback independent of maps?
Assume bpf_mem_alloc is already available and NMI prog can allocate a typed object.
The usage could be:
struct my_work {
  int a;
  struct task_struct __kptr_ref *t;
};
void my_cb(struct my_work *w);

struct my_work *w = bpf_mem_alloc(allocator, bpf_core_type_id_local(*w));
w->t = ..;
bpf_submit_work(w, my_cb, SLEEPABLE | IRQ_WORK);

Am I day dreaming? :)