On Tue, Mar 13, 2018 at 03:42:20PM -0700, Alexei Starovoitov wrote: > On 3/13/18 3:13 PM, Tejun Heo wrote: > > Hello, > > > > On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: > > > it has to be zero lookups. If idr lookup is involved, it's cleaner > > > to add idr as new bpf map type and use cgroup ino as an id. > > > > Oh, idr (or rather ida) is just to allocate the key, once the key is > > there it pretty much should boil down to sth like > > > > rcu_read_lock(); > > table = rcu_deref(cgrp->table); > > if (key < table->len) > > ret = table[key]; > > else > > ret = NULL; > > rcu_read_unlock(); > > > > Depending on the requirements, we can get rid of the table->len check > > by making key alloc path more expensive (ie. give out key only after > > table extension is fully done and propagated). > > just like two bpf progs can be attached to the same cgroup > the same bpf prog can be attached to multiple cgroups. > If we use ida to allocate an id and store it bpf->aux->cgroup_table_key > to later do: cgrp->table[bpf->aux->cgroup_table_key] > this id==key would need to valid across multiple cgroups which > complicates things a lot. > > It feels that we need something similar to compute_effective_progs() > but for this scratch buffers. > Then at the time of BPF_PROG_RUN_ARRAY supply corresponding > scratch buffer for every program. > Next to cgrp->bpf.effective[type] have similar array of pointers > to scratch buffers. Sorry, if I wasn't clear, this is exactly what I mean in my prev letter: make a pointer to a scratch buffer unique per (cgroup, attached program) pair. Then we'll have zero lookups on a hot path, but keep the flexibility.. Sounds very good to me. Thanks! -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
