On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote:
> On 3/13/18 1:50 PM, Tejun Heo wrote:
> > Hello, Matt.
> >
> > cc'ing Roman and Alexei.
> >
> > On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
> > > There are cases where other parts of the kernel may wish to store data
> > > associated with individual cgroups without building a full cgroup
> > > controller. Let's add interfaces to allow them to register and lookup
> > > this private data for individual cgroups.
> > >
> > > A kernel system (e.g., a driver) that wishes to register private data
> > > for a cgroup will do so by subclassing the 'struct cgroup_priv'
> > > structure to describe the necessary data to store. Before registering a
> > > private data structure to a cgroup, the caller should fill in the 'key'
> > > and 'free' fields of the base cgroup_priv structure.
> > >
> > > * 'key' should be a unique void* that will act as a key for future
> > > privdata lookups/removals. Note that this allows drivers to store
> > > per-device private data for a cgroup by using a device pointer as a key.
> > >
> > > * 'free' should be a function pointer to a function that may be used
> > > to destroy the private data. This function will be called
> > > automatically if the underlying cgroup is destroyed.
> >
> > This feature turned out to have more users than I originally
> > anticipated and bpf also wants something like this to track network
> > states. The requirements are pretty similar but not quite the same.
> > The extra requirements are...
> >
> > * Lookup must be really cheap. Probably using pointer hash or walking
> > list isn't great, so maybe idr based lookup + RCU protected index
> > table per cgroup?
> >
> > * It should support both regular memory and percpu pointers. Given
> > that what cgroup does is pretty much cgroup:key -> pointer lookup,
> > it's mostly about getting the interface right so that it's not too
> > error-prone.
>
> from bpf side there should be _zero_ lookups.
> If bpf do a lookup it can equally use its own map to do that.
>
> From bpf program point of view it will look like:
> struct my_data {
> u64 a;
> u32 b;
> } *ptr;
> ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
>
> bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
> dereferences
> skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get pointer
> to the buffer.
Having strictly one buffer per-cgroup sounds very limiting.
What if two independent bpf programs start using it?
> In good case it may be optimized (inlined) by the verifier into absolute
> address of that cgroup scratch buffer at attach time.
Maybe we can have an idr-based index table (as Tejun suggested above),
but avoid performance penalty by optimizing the lookup out at the attach time?
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
