> On Mar 31, 2021, at 9:26 PM, Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote: > > From: Cong Wang <cong.wang@xxxxxxxxxxxxx> > > (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 [...]
