On Mon, May 24, 2021 at 12:13 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > 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. > 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. Very clearly, whatever you described as "single shot" is not what we want from any perspective. Thanks.
