[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWwGNnVtdUdnMp4P2pazp5te-rHEXMU7h-9KYg27BM1tA@mail.gmail.com>
Date: Thu, 10 Jun 2021 23:47:37 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: David Miller <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, kernel-team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 0/3] bpf: Introduce BPF timers.
On Thu, Jun 10, 2021 at 9:26 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> From: Alexei Starovoitov <ast@...nel.org>
>
> v1->v2:
> - Addressed great feedback from Andrii and Toke.
> - Fixed race between parallel bpf_timer_*() ops.
> - Fixed deadlock between timer callback and LRU eviction or bpf_map_delete/update.
> - Disallowed mmap and global timers.
> - Allow bpf_spin_lock and bpf_timer in an element. One of each.
> - Fixed memory leaks due to map destruction and LRU eviction.
> - Add support for specifying clockid in bpf_timer_init.
> - Make bpf_timer helpers gpl_only.
> - Fix key pointer in callback_fn when bpf_timer is inside array.
> - A ton more tests.
>
> The 1st patch implements interaction between bpf programs and bpf core.
> The 2nd patch implements necessary safety checks.
> The 3rd patch is the test.
What is your use case to justify your own code? Asking because
you deny mine, so clearly my use case is not yours.
And more importantly, why not just use BPF_TEST_RUN with
a user-space timer? Asking because you offer no API to read or
modify timer expiration, so literally the same with BPF_TEST_RUN
approach.
Thanks.
Powered by blists - more mailing lists