On Wed, Mar 17, 2021 at 10:26 AM Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
>
> On Tue, Mar 16, 2021 at 9:21 PM Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
> > We still need a timer map:
> >
> > struct {
> > __uint(type, BPF_MAP_TYPE_TIMER);
> > } map SEC(".maps");
> >
> > However, its key is not a pointer to timer, it is a timer ID allocated with
> >
> > u32 bpf_timer_create(void *callback, void *arg, u64 flags);
>
> Hmm, we do not need a map at all, because the verifier could check
> whether create() and delete() are paired correctly, so we can just
> have the following API's:
>
> u32 bpf_timer_create(void *callback, void *arg, u32 flags);
> void bpf_timer_settime(u32 id, u64 expires);
> u64 bpf_timer_gettime(u32 id);
> int bpf_timer_delete(u32 id);
>
> Pretty much similar to Linux user-space timer API's. I will probably
> go this direction, unless there is any objection.
I think a specialized map or hidden map that returns id like above
has plenty of downsides.
Please reconsider what I was proposing.
In the previous email I outlined the reasons why 'struct bpf_timer'
embedded in any normal map is more user friendly and more flexible.
I'd like to discuss those points first. It sounds to me that you disagreed,
but I couldn't find an articulation on why you disagreed.
