Re: [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

[Roman Gushchin <guro@fb.com>]

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!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx