On Wed, Jan 27, 2021 at 10:28:15PM -0800, Cong Wang wrote:
> On Wed, Jan 27, 2021 at 10:00 AM Alexei Starovoitov
> <[email protected]> wrote:
> >
> > On Tue, Jan 26, 2021 at 11:00 PM Cong Wang <[email protected]> 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.
