Re: [RFC PATCH bpf-next] bpf: Introduce bpf_timer

On Mon, May 24, 2021 at 10:22 PM Cong Wang [off-list ref] wrote:

On Mon, May 24, 2021 at 12:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

I second the use of BPF_PROG_TEST_RUN (a.k.a. BPF_PROG_RUN now) to
"mirror" such APIs to user-space. We have so much BPF-side

Except the expiration time is stored in user-space too if you just
use user-space timers to trigger BPF_PROG_TEST_RUN.
Modifying expiration based on its current value in timer callbacks
is very common. For example in conntrack use case, we want the
GC timer to run sooner in the next run if we get certain amount of
expired items in current run.

I'm not entirely sure what all this means, sorry. My general point is
that instead of doing bpf() syscall with a new custom command (e.g.,
BPF_TIMER_UPDATE), you can just fire your custom BPF program with
BPF_TEST_RUN. You can pass custom timeouts or any other
user-space-provided settings either through global variables, custom
maps, or directly as a context. So you have full control over what
should be set when and why, we just avoid adding tons of custom bpf()
syscall commands for every single feature.

quoted

functionality and APIs that reflecting all of that with special
user-space-facing BPF commands is becoming quite impractical. E.g., a
long time ago there was a proposal to add commands to push data to BPF
ringbuf from user-space for all kinds of testing scenarios. We never
did that because no one bothered enough, but now I'd advocate that a
small custom BPF program that is single-shot through BPF_PROG_RUN is a
better way to do this. Similarly for timers and whatever other
functionality. By doing everything from BPF program we also side-step
potential subtle differences in semantics between BPF-side and
user-space-side.

I am confused about what you are saying, because we can already
trigger BPF_PROG_RUN with a user-space timer for a single shot,
with the current kernel, without any modification. So this sounds like
you are against adding any timer on the eBPF side, but on the other
hand, you are secoding to Alexei's patch... I am completely lost.

I'm arguing against adding more custom commands to bpf() syscall. And
I was talking about triggering BPF program directly from user-space
with BPF_PROG_TEST_RUN/BPF_PROG_RUN command, not through some timers.

Very clearly, whatever you described as "single shot" is not what we
want from any perspective.

I'm not sure we are even talking about the same things, so I doubt
"clearly" in this case.

Thanks.