Message ID | 20210122205415.113822-1-xiyou.wangcong@gmail.com |
---|---|
Headers | show |
Series | bpf: introduce timeout hash map | expand |
On 1/22/21 9:54 PM, Cong Wang wrote: > From: Cong Wang <cong.wang@bytedance.com> > > This borrows the idea from conntrack and will be used for conntrack in > ebpf too. Each element in a timeout map has a user-specified timeout > in msecs, after it expires it will be automatically removed from the > map. Cilium already does the same thing, it uses a regular map or LRU > map to track connections and has its own GC in user-space. This does > not scale well when we have millions of connections, as each removal > needs a syscall. Even if we could batch the operations, it still needs > to copy a lot of data between kernel and user space. > > There are two cases to consider here: > > 1. When the timeout map is idle, i.e. no one updates or accesses it, > we rely on the delayed work to scan the whole hash table and remove > these expired. The delayed work is scheduled every 1 sec when idle, > which is also what conntrack uses. It is fine to scan the whole > table as we do not actually remove elements during this scan, > instead we simply queue them to the lockless list and defer all the > removals to the next schedule. > > 2. When the timeout map is actively accessed, we could reach expired > elements before the idle work automatically scans them, we can > simply skip them and schedule the delayed work immediately to do > the actual removals. We have to avoid taking locks on fast path. > > The timeout of an element can be set or updated via bpf_map_update_elem() > and we reuse the upper 32-bit of the 64-bit flag for the timeout value, > as there are only a few bits are used currently. Note, a zero timeout > means to expire immediately. > > To avoid adding memory overhead to regular map, we have to reuse some > field in struct htab_elem, that is, lru_node. Otherwise we would have > to rewrite a lot of code. > > For now, batch ops is not supported, we can add it later if needed. Back in earlier conversation [0], I mentioned also LRU map flavors and to look into adding a flag, so we wouldn't need new BPF_MAP_TYPE_TIMEOUT_HASH/*LRU types that replicate existing types once again just with the timeout in addition, so UAPI wise new map type is not great. Given you mention Cilium above, only for kernels where there is no LRU hash map, that is < 4.10, we rely on plain hash, everything else LRU + prealloc to mitigate ddos by refusing to add new entries when full whereas less active ones will be purged instead. Timeout /only/ for plain hash is less useful overall, did you sketch a more generic approach in the meantime that would work for all the htab/lru flavors (and ideally as non-delayed_work based)? [0] https://lore.kernel.org/bpf/20201214201118.148126-1-xiyou.wangcong@gmail.com/ [...] > @@ -1012,6 +1081,8 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > copy_map_value_locked(map, > l_old->key + round_up(key_size, 8), > value, false); > + if (timeout_map) > + l_old->expires = msecs_to_expire(timeout); > return 0; > } > /* fall through, grab the bucket lock and lookup again. > @@ -1020,6 +1091,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > */ > } > > +again: > ret = htab_lock_bucket(htab, b, hash, &flags); > if (ret) > return ret; > @@ -1040,26 +1112,41 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > copy_map_value_locked(map, > l_old->key + round_up(key_size, 8), > value, false); > + if (timeout_map) > + l_old->expires = msecs_to_expire(timeout); > ret = 0; > goto err; > } > > l_new = alloc_htab_elem(htab, key, value, key_size, hash, false, false, > - l_old); > + timeout_map, l_old); > if (IS_ERR(l_new)) { > - /* all pre-allocated elements are in use or memory exhausted */ > ret = PTR_ERR(l_new); > + if (ret == -EAGAIN) { > + htab_unlock_bucket(htab, b, hash, flags); > + htab_gc_elem(htab, l_old); > + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > + goto again; Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? > + } > + /* all pre-allocated elements are in use or memory exhausted */ > goto err; > } > > + if (timeout_map) > + l_new->expires = msecs_to_expire(timeout); > +
On Tue, Jan 26, 2021 at 2:04 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 1/22/21 9:54 PM, Cong Wang wrote: > > From: Cong Wang <cong.wang@bytedance.com> > > > > This borrows the idea from conntrack and will be used for conntrack in > > ebpf too. Each element in a timeout map has a user-specified timeout > > in msecs, after it expires it will be automatically removed from the > > map. Cilium already does the same thing, it uses a regular map or LRU > > map to track connections and has its own GC in user-space. This does > > not scale well when we have millions of connections, as each removal > > needs a syscall. Even if we could batch the operations, it still needs > > to copy a lot of data between kernel and user space. > > > > There are two cases to consider here: > > > > 1. When the timeout map is idle, i.e. no one updates or accesses it, > > we rely on the delayed work to scan the whole hash table and remove > > these expired. The delayed work is scheduled every 1 sec when idle, > > which is also what conntrack uses. It is fine to scan the whole > > table as we do not actually remove elements during this scan, > > instead we simply queue them to the lockless list and defer all the > > removals to the next schedule. > > > > 2. When the timeout map is actively accessed, we could reach expired > > elements before the idle work automatically scans them, we can > > simply skip them and schedule the delayed work immediately to do > > the actual removals. We have to avoid taking locks on fast path. > > > > The timeout of an element can be set or updated via bpf_map_update_elem() > > and we reuse the upper 32-bit of the 64-bit flag for the timeout value, > > as there are only a few bits are used currently. Note, a zero timeout > > means to expire immediately. > > > > To avoid adding memory overhead to regular map, we have to reuse some > > field in struct htab_elem, that is, lru_node. Otherwise we would have > > to rewrite a lot of code. > > > > For now, batch ops is not supported, we can add it later if needed. > > Back in earlier conversation [0], I mentioned also LRU map flavors and to look > into adding a flag, so we wouldn't need new BPF_MAP_TYPE_TIMEOUT_HASH/*LRU types > that replicate existing types once again just with the timeout in addition, so > UAPI wise new map type is not great. Interestingly, Jamal also brought this flag up to me. The reason why I don't use a flag is that I don't see any other maps need a timeout. Take the LRU map you mentioned as an example, it evicts elements based on size, not based on time, I can't think of a case where we need both time and size based eviction. Another example is array, there is no way to delete an element from an array, so we can't really expire an element. Or do you have any use case for a non-regular hash map with timeout? > > Given you mention Cilium above, only for kernels where there is no LRU hash map, > that is < 4.10, we rely on plain hash, everything else LRU + prealloc to mitigate > ddos by refusing to add new entries when full whereas less active ones will be > purged instead. Timeout /only/ for plain hash is less useful overall, did you The difference between LRU and a timeout map is whether we should drop the least recently used one too when it is full. For conntrack, this is not a good idea, because when we have a burst of connections, the least recently used might be just 1-s old, so evicting it out is not a good idea. With a timeout map, we just drop all new connection when it is full and wait for some connect to timeout naturally, aligned with the definition of conntrack. So it should be a good replacement for LRU map too in terms of conntrack. > sketch a more generic approach in the meantime that would work for all the htab/lru > flavors (and ideally as non-delayed_work based)? If you mean LRU maps may need timeout too, like I explained above, I can't think of any such use cases. > > [0] https://lore.kernel.org/bpf/20201214201118.148126-1-xiyou.wangcong@gmail.com/ > > [...] > > @@ -1012,6 +1081,8 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > > copy_map_value_locked(map, > > l_old->key + round_up(key_size, 8), > > value, false); > > + if (timeout_map) > > + l_old->expires = msecs_to_expire(timeout); > > return 0; > > } > > /* fall through, grab the bucket lock and lookup again. > > @@ -1020,6 +1091,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > > */ > > } > > > > +again: > > ret = htab_lock_bucket(htab, b, hash, &flags); > > if (ret) > > return ret; > > @@ -1040,26 +1112,41 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, > > copy_map_value_locked(map, > > l_old->key + round_up(key_size, 8), > > value, false); > > + if (timeout_map) > > + l_old->expires = msecs_to_expire(timeout); > > ret = 0; > > goto err; > > } > > > > l_new = alloc_htab_elem(htab, key, value, key_size, hash, false, false, > > - l_old); > > + timeout_map, l_old); > > if (IS_ERR(l_new)) { > > - /* all pre-allocated elements are in use or memory exhausted */ > > ret = PTR_ERR(l_new); > > + if (ret == -EAGAIN) { > > + htab_unlock_bucket(htab, b, hash, flags); > > + htab_gc_elem(htab, l_old); > > + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > > + goto again; > > Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting > in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? In this case, the old one is scheduled for removal in GC, we just wait for GC to finally remove it. It won't stall unless GC itself or the worker scheduler is wrong, both of which should be kernel bugs. If we don't do this, users would get a -E2BIG when it is not too big. I don't know a better way to handle this sad situation, maybe returning -EBUSY to users and let them call again? Thanks.
On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > ret = PTR_ERR(l_new); > > > + if (ret == -EAGAIN) { > > > + htab_unlock_bucket(htab, b, hash, flags); > > > + htab_gc_elem(htab, l_old); > > > + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > > > + goto again; > > > > Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting > > in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? > > In this case, the old one is scheduled for removal in GC, we just wait for GC > to finally remove it. It won't stall unless GC itself or the worker scheduler is > wrong, both of which should be kernel bugs. > > If we don't do this, users would get a -E2BIG when it is not too big. I don't > know a better way to handle this sad situation, maybe returning -EBUSY > to users and let them call again? I think using wq for timers is a non-starter. Tying a hash/lru map with a timer is not a good idea either. I think timers have to be done as independent objects similar to how the kernel uses them. Then there will be no question whether lru or hash map needs it. The bpf prog author will be able to use timers with either. The prog will be able to use timers without hash maps too. I'm proposing a timer map where each object will go through bpf_timer_setup(timer, callback, flags); where "callback" is a bpf subprogram. Corresponding bpf_del_timer and bpf_mod_timer would work the same way they are in the kernel. The tricky part is kernel style of using from_timer() to access the object with additional info. I think bpf timer map can model it the same way. At map creation time the value_size will specify the amount of extra bytes necessary. Another alternative is to pass an extra data argument to a callback.
On 1/27/21 7:00 PM, Alexei Starovoitov wrote: > On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: >>>> ret = PTR_ERR(l_new); >>>> + if (ret == -EAGAIN) { >>>> + htab_unlock_bucket(htab, b, hash, flags); >>>> + htab_gc_elem(htab, l_old); >>>> + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); >>>> + goto again; >>> >>> Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting >>> in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? >> >> In this case, the old one is scheduled for removal in GC, we just wait for GC >> to finally remove it. It won't stall unless GC itself or the worker scheduler is >> wrong, both of which should be kernel bugs. >> >> If we don't do this, users would get a -E2BIG when it is not too big. I don't >> know a better way to handle this sad situation, maybe returning -EBUSY >> to users and let them call again? > > I think using wq for timers is a non-starter. > Tying a hash/lru map with a timer is not a good idea either. Thinking some more, given we have jiffies64 helper and atomic ops for BPF by now, we would technically only need the ability to delete entries via bpf iter progs (d6c4503cc296 ("bpf: Implement bpf iterator for hash maps")) which could then be kicked off from user space at e.g. dynamic intervals which would be the equivalent for the wq in here. That patch could then be implemented this way. I presume the ability to delete map entries from bpf iter progs would be generic and useful enough anyway. > I think timers have to be done as independent objects similar to > how the kernel uses them. > Then there will be no question whether lru or hash map needs it. > The bpf prog author will be able to use timers with either. > The prog will be able to use timers without hash maps too. > > I'm proposing a timer map where each object will go through > bpf_timer_setup(timer, callback, flags); > where "callback" is a bpf subprogram. > Corresponding bpf_del_timer and bpf_mod_timer would work the same way > they are in the kernel. > The tricky part is kernel style of using from_timer() to access the > object with additional info. Would this mean N timer objs for N map elems? I presume not given this could be racy and would have huge extra mem overhead. Either way, timer obj could work, but then at the same time you could probably also solve it with the above; it's not like you need the timer to kick in at some /exact/ time, but rather at some point to clean up stale entries before the map gets full and worst case refuses updates for new entries. (In the ideal case though we wouldn't need the extra effort to search deeply for elements w/o penalizing the fast-path lookup costs too much when walking the bucket.) > I think bpf timer map can model it the same way. > At map creation time the value_size will specify the amount of extra > bytes necessary. > Another alternative is to pass an extra data argument to a callback.
On Wed, Jan 27, 2021 at 2:48 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 1/27/21 7:00 PM, Alexei Starovoitov wrote: > > On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > >>>> ret = PTR_ERR(l_new); > >>>> + if (ret == -EAGAIN) { > >>>> + htab_unlock_bucket(htab, b, hash, flags); > >>>> + htab_gc_elem(htab, l_old); > >>>> + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > >>>> + goto again; > >>> > >>> Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting > >>> in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? > >> > >> In this case, the old one is scheduled for removal in GC, we just wait for GC > >> to finally remove it. It won't stall unless GC itself or the worker scheduler is > >> wrong, both of which should be kernel bugs. > >> > >> If we don't do this, users would get a -E2BIG when it is not too big. I don't > >> know a better way to handle this sad situation, maybe returning -EBUSY > >> to users and let them call again? > > > > I think using wq for timers is a non-starter. > > Tying a hash/lru map with a timer is not a good idea either. > > Thinking some more, given we have jiffies64 helper and atomic ops for BPF by now, > we would technically only need the ability to delete entries via bpf iter progs > (d6c4503cc296 ("bpf: Implement bpf iterator for hash maps")) which could then be > kicked off from user space at e.g. dynamic intervals which would be the equivalent > for the wq in here. That patch could then be implemented this way. I presume > the ability to delete map entries from bpf iter progs would be generic and useful > enough anyway. I think bpf_iter for maps doesn't hold bucket lock anymore, so delete of the same element should be allowed already. Unless I've mistaken wip patches with landed ones. Soon there will be support for bpf_map_for_each_elem() iterator running from the bpf program itself, so even more ways to do GC like work. > > I think timers have to be done as independent objects similar to > > how the kernel uses them. > > Then there will be no question whether lru or hash map needs it. > > The bpf prog author will be able to use timers with either. > > The prog will be able to use timers without hash maps too. > > > > I'm proposing a timer map where each object will go through > > bpf_timer_setup(timer, callback, flags); > > where "callback" is a bpf subprogram. > > Corresponding bpf_del_timer and bpf_mod_timer would work the same way > > they are in the kernel. > > The tricky part is kernel style of using from_timer() to access the > > object with additional info. > > Would this mean N timer objs for N map elems? I presume not given this could be > racy and would have huge extra mem overhead. hmm. Not sure I got the point about overhead. sizeof(struct timer_list) == 40 bytes. Not a lot of overhead even if there is a timer object per flow. When bpf_map_for_each_elem() lands the bpf prog could have one timer that will kick one a second (or whatever GC period the prog author wants) and does bpf_map_for_each_elem() once callback fires to delete elems older than whatever interval the prog needs. imo that would be a true generic way to combine bpf_maps, bpf_iters and bpf_timers. > Either way, timer obj could work, but > then at the same time you could probably also solve it with the above; it's not > like you need the timer to kick in at some /exact/ time, but rather at some point > to clean up stale entries before the map gets full and worst case refuses updates > for new entries. (In the ideal case though we wouldn't need the extra effort to > search deeply for elements w/o penalizing the fast-path lookup costs too much when > walking the bucket.) Right. I wasn't suggesting to mess with the timer object at every lookup. My understanding that mod_timer() isn't that fast to call a million times a second. bpf progs would have to be smart. Instead of timer objects as a timer map (a collection of timers that bpf progs can manipulate) we can introduce them similar to "struct bpf_spin_lock". Then "struct bpf_timer foo;" field can be embedded inside any map value (both hash and array). The verifier work would be a bit trickier than support for bpf_spin_lock, but certainly doable. My main point was that bpf should grow with small composable building blocks instead of single purpose constructs. I view hashmap+GC as an example of something that should be split into smaller blocks.
On Wed, Jan 27, 2021 at 10:00 AM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > ret = PTR_ERR(l_new); > > > > + if (ret == -EAGAIN) { > > > > + htab_unlock_bucket(htab, b, hash, flags); > > > > + htab_gc_elem(htab, l_old); > > > > + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > > > > + goto again; > > > > > > Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting > > > in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? > > > > In this case, the old one is scheduled for removal in GC, we just wait for GC > > to finally remove it. It won't stall unless GC itself or the worker scheduler is > > wrong, both of which should be kernel bugs. > > > > If we don't do this, users would get a -E2BIG when it is not too big. I don't > > know a better way to handle this sad situation, maybe returning -EBUSY > > to users and let them call again? > > I think using wq for timers is a non-starter. > Tying a hash/lru map with a timer is not a good idea either. Both xt_hashlimit and nf_conntrack_core use delayed/deferrable works, probably since their beginnings. They seem to have started well. ;) > > I think timers have to be done as independent objects similar to > how the kernel uses them. > Then there will be no question whether lru or hash map needs it. Yeah, this probably could make the code easier, but when we have millions of entries in a map, millions of timers would certainly bring a lot of CPU overhead (timer interrupt storm?). > The bpf prog author will be able to use timers with either. > The prog will be able to use timers without hash maps too. > > I'm proposing a timer map where each object will go through > bpf_timer_setup(timer, callback, flags); > where "callback" is a bpf subprogram. > Corresponding bpf_del_timer and bpf_mod_timer would work the same way > they are in the kernel. > The tricky part is kernel style of using from_timer() to access the > object with additional info. > I think bpf timer map can model it the same way. > At map creation time the value_size will specify the amount of extra > bytes necessary. > Another alternative is to pass an extra data argument to a callback. Hmm, this idea is very interesting. I still think arming a timer, whether a kernel timer or a bpf timer, for each entry is overkill, but we can arm one for each map, something like: bpf_timer_run(interval, bpf_prog, &any_map); so we run 'bpf_prog' on any map every 'interval', but the 'bpf_prog' would have to iterate the whole map during each interval to delete the expired ones. This is probably doable: the timestamps can be stored either as a part of key or value, and bpf_jiffies64() is already available, users would have to discard expired ones after lookup when they are faster than the timer GC. Let me take a deeper look tomorrow. Thanks.
On Wed, Jan 27, 2021 at 10:28:15PM -0800, Cong Wang wrote: > On Wed, Jan 27, 2021 at 10:00 AM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > > ret = PTR_ERR(l_new); > > > > > + if (ret == -EAGAIN) { > > > > > + htab_unlock_bucket(htab, b, hash, flags); > > > > > + htab_gc_elem(htab, l_old); > > > > > + mod_delayed_work(system_unbound_wq, &htab->gc_work, 0); > > > > > + goto again; > > > > > > > > Also this one looks rather worrying, so the BPF prog is stalled here, loop-waiting > > > > in (e.g. XDP) hot path for system_unbound_wq to kick in to make forward progress? > > > > > > In this case, the old one is scheduled for removal in GC, we just wait for GC > > > to finally remove it. It won't stall unless GC itself or the worker scheduler is > > > wrong, both of which should be kernel bugs. > > > > > > If we don't do this, users would get a -E2BIG when it is not too big. I don't > > > know a better way to handle this sad situation, maybe returning -EBUSY > > > to users and let them call again? > > > > I think using wq for timers is a non-starter. > > Tying a hash/lru map with a timer is not a good idea either. > > Both xt_hashlimit and nf_conntrack_core use delayed/deferrable > works, probably since their beginnings. They seem to have started > well. ;) That code was written when network speed was in Mbits and DDoS abbreviation wasn't invented. Things are different now. > > I'm proposing a timer map where each object will go through > > bpf_timer_setup(timer, callback, flags); > > where "callback" is a bpf subprogram. > > Corresponding bpf_del_timer and bpf_mod_timer would work the same way > > they are in the kernel. > > The tricky part is kernel style of using from_timer() to access the > > object with additional info. > > I think bpf timer map can model it the same way. > > At map creation time the value_size will specify the amount of extra > > bytes necessary. > > Another alternative is to pass an extra data argument to a callback. > > Hmm, this idea is very interesting. I still think arming a timer, > whether a kernel timer or a bpf timer, for each entry is overkill, > but we can arm one for each map, something like: > > bpf_timer_run(interval, bpf_prog, &any_map); > > so we run 'bpf_prog' on any map every 'interval', but the 'bpf_prog' > would have to iterate the whole map during each interval to delete > the expired ones. This is probably doable: the timestamps can be > stored either as a part of key or value, and bpf_jiffies64() is already > available, users would have to discard expired ones after lookup > when they are faster than the timer GC. I meant it would look like: noinline per_elem_callback(map, key, value, ...) { if (value->foo > ...) bpf_delete_map_elem(map, key); } noinline timer_callback(timer, ctx) { map = ctx->map; bpf_for_each_map_elem(map, per_elem_callback, ...); } int main_bpf_prog(skb) { bpf_timer_setup(my_timer, timer_callback, ...); bpf_mod_timer(my_timer, HZ); } The bpf_for_each_map_elem() work is already in progress. Expect patches to hit mailing list soon. If you can work on patches for bpf_timer_*() it would be awesome.
On Thu, Jan 28, 2021 at 6:54 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > I meant it would look like: > > noinline per_elem_callback(map, key, value, ...) > { > if (value->foo > ...) > bpf_delete_map_elem(map, key); > } > > noinline timer_callback(timer, ctx) > { > map = ctx->map; > bpf_for_each_map_elem(map, per_elem_callback, ...); > } > > int main_bpf_prog(skb) > { > bpf_timer_setup(my_timer, timer_callback, ...); > bpf_mod_timer(my_timer, HZ); > } > > The bpf_for_each_map_elem() work is already in progress. Expect patches to hit > mailing list soon. We don't want a per-element timer, we want a per-map timer but that requires a way to iterate the whole map. If you or other can provide bpf_for_each_map_elem(), we can certainly build our timeout map on top of it. > If you can work on patches for bpf_timer_*() it would be awesome. Yeah, I will work on this, not only for timeout map, but also possibly for the ebpf qdisc I plan to add soon. Thanks.
On 1/28/21 9:57 PM, Cong Wang wrote: > On Thu, Jan 28, 2021 at 6:54 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: >> >> I meant it would look like: >> >> noinline per_elem_callback(map, key, value, ...) >> { >> if (value->foo > ...) >> bpf_delete_map_elem(map, key); >> } >> >> noinline timer_callback(timer, ctx) >> { >> map = ctx->map; >> bpf_for_each_map_elem(map, per_elem_callback, ...); >> } >> >> int main_bpf_prog(skb) >> { >> bpf_timer_setup(my_timer, timer_callback, ...); >> bpf_mod_timer(my_timer, HZ); >> } >> >> The bpf_for_each_map_elem() work is already in progress. Expect patches to hit >> mailing list soon. > > We don't want a per-element timer, we want a per-map timer but that > requires a way to iterate the whole map. If you or other can provide > bpf_for_each_map_elem(), we can certainly build our timeout map > on top of it. I am working on this. Still need a few weeks to post RFC. Will share as soon as it is in reasonable shape. Thanks! > >> If you can work on patches for bpf_timer_*() it would be awesome. > > Yeah, I will work on this, not only for timeout map, but also possibly for > the ebpf qdisc I plan to add soon. > > Thanks. >
On Fri, Jan 29, 2021 at 6:14 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > On 2021-01-29 9:06 a.m., Jamal Hadi Salim wrote: > > > Which leads to: > > Why not extend the general feature so one can register for optional > > callbacks not just for expire but also add/del/update on specific > > entries or table? > > add/del/update could be sourced from other kernel programs or user space > > and the callback would be invoked before an entry is added/deleted etc. > > (just like it is here for expiry). > > Sorry - shouldve read the rest of the thread: > Agree with Cong that you want per-map but there are use cases where you > want it per entry (eg the add/del/update case). That was my point as well. bpf_timer api should be generic, so that users can do both. The program could use bpf_timer one for each flow and bpf_timer for each map. And timers without maps.
On 2021-01-29 10:14 p.m., Alexei Starovoitov wrote: > On Fri, Jan 29, 2021 at 6:14 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote: >> >> On 2021-01-29 9:06 a.m., Jamal Hadi Salim wrote: >> >>> Which leads to: >>> Why not extend the general feature so one can register for optional >>> callbacks not just for expire but also add/del/update on specific >>> entries or table? >>> add/del/update could be sourced from other kernel programs or user space >>> and the callback would be invoked before an entry is added/deleted etc. >>> (just like it is here for expiry). >> >> Sorry - shouldve read the rest of the thread: >> Agree with Cong that you want per-map but there are use cases where you >> want it per entry (eg the add/del/update case). > > That was my point as well. > bpf_timer api should be generic, so that users can do both. > The program could use bpf_timer one for each flow and bpf_timer for each map. > And timers without maps. I like it. Sensible to also have callback invocations for map changes i.e entry create/update/delete (maybe map create/destroy). cheers, jamal
From: Cong Wang <cong.wang@bytedance.com> This patchset introduces a new eBPF hash map whose elements have timeouts. Patch 1 is the implementation of timeout map, patch 2 adds some test cases for timeout map in test_maps, and patch 3 adds a test case in map ptr test. This patchset has been tested with the provided test cases for hours. Please check each patch description for more details. --- v5: add a lost piece of patch during rebase fix the extra_elems corner case add a stress test case v4: merge gc_work into gc_idle_work to avoid a nasty race condition fix a potential use-after-free add one more test case improve comments and update changelog v3: move gc list from bucket to elem reuse lru_node in struct htab_elem drop patches which are no longer necessary fix delete path add a test case for delete path add parallel test cases change timeout to ms drop batch ops v2: fix hashmap ptr test add a test case in map ptr test factor out htab_timeout_map_alloc() Cong Wang (3): bpf: introduce timeout hash map selftests/bpf: add test cases for bpf timeout map selftests/bpf: add timeout map check in map_ptr tests include/linux/bpf_types.h | 1 + include/uapi/linux/bpf.h | 5 +- kernel/bpf/hashtab.c | 274 +++++++++++++++++- kernel/bpf/syscall.c | 3 +- tools/include/uapi/linux/bpf.h | 1 + .../selftests/bpf/progs/map_ptr_kern.c | 20 ++ tools/testing/selftests/bpf/test_maps.c | 68 +++++ 7 files changed, 357 insertions(+), 15 deletions(-)