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.
We probably need to think through how the same mechanism can be
used for per-socket scratch buffers.
--
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
