> On Mar 31, 2021, at 9:26 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> 
> From: Cong Wang <cong.w...@bytedance.com>
> 
> (This patch is still in early stage and obviously incomplete. I am sending
> it out to get some high-level feedbacks. Please kindly ignore any coding
> details for now and focus on the design.)

Could you please explain the use case of the timer? Is it the same as 
earlier proposal of BPF_MAP_TYPE_TIMEOUT_HASH? 

Assuming that is the case, I guess the use case is to assign an expire 
time for each element in a hash map; and periodically remove expired 
element from the map. 

If this is still correct, my next question is: how does this compare
against a user space timer? Will the user space timer be too slow?

> 
> This patch introduces a bpf timer map and a syscall to create bpf timer
> from user-space.
> 
> The reason why we have to use a map is because the lifetime of a timer,
> without a map, we have to delete the timer before exiting the eBPF program,
> this would significately limit its use cases. With a map, the timer can
> stay as long as the map itself and can be actually updated via map update
> API's too, where the key is the timer ID and the value is the timer expire
> timer.
> 
> Timer creation is not easy either. In order to prevent users creating a
> timer but not adding it to a map, we have to enforce this in the API which
> takes a map parameter and adds the new timer into the map in one shot.

I think we don't have to address "creating a timer but not adding it to a map" 
problem in the kernel. If the user forgot it, the user should debug it. 

Thanks,
Song

[...]

Reply via email to