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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux