Thread (28 messages) flat view 28 messages, 5 authors, 2021-07-01

Re: [PATCH v3 bpf-next 1/8] bpf: Introduce bpf timers.

From: Alexei Starovoitov <hidden>
Date: 2021-06-29 03:32:31
Also in: bpf

On Mon, Jun 28, 2021 at 07:24:28PM -0700, Yonghong Song wrote:
quoted
While talking to Martin about the api he pointed out that
callback_fn in timer_start() doesn't achieve the full use case
of replacing a prog. So in the next spin I'll split it into
bpf_timer_set_callback(timer, callback_fn);
bpf_timer_start(timer, nsec);
This way callback and prog can be replaced without resetting
timer expiry which could be useful.
I took a brief look for patch 4-6 and it looks okay. But since
you will change helper signatures I will hold and check next
revision instead.
Thanks. The verifier patches won't change though.
BTW, does this mean the following scenario will be supported?
  prog1: bpf_timer_set_callback(time, callback_fn)
  prog2: bpf_timer_start(timer, nsec)
so here prog2 can start the timer which call prog1's callback_fn?
right.
quoted
Also Daniel and Andrii reminded that cpu pinning would be next
feature request. The api extensibility allows to add it in the future.
I'm going to delay implementing it until bpf_smp_call_single()
implications are understood.
Do we need to any a 'flags' parameter for bpf_timer_start() helper
so we can encode target cpu in 'flags'?
I thought that bpf_timer_init will handle the cpu selection,
but you're right that having cpu in bpf_timer_start is more flexible.
So I'll add a flag.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help