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

[Alexei Starovoitov <ast@fb.com>]

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.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx