Re: [PATCH bpf-next v4] bpf: increase supported cgroup storage value size

[sdf@google.com]

On 07/27, Andrii Nakryiko wrote:
> On Tue, Jul 27, 2021 at 3:23 PM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > Current max cgroup storage value size is 4k (PAGE_SIZE). The other local
> > storages accept up to 64k (BPF_LOCAL_STORAGE_MAX_VALUE_SIZE). Let's  
> align
> > max cgroup value size with the other storages.
> >
> > For percpu, the max is 32k (PCPU_MIN_UNIT_SIZE) because percpu
> > allocator is not happy about larger values.
> >
> > netcnt test is extended to exercise those maximum values
> > (non-percpu max size is close to, but not real max).
> >
> > v4:
> > * remove inner union (Andrii Nakryiko)
> > * keep net_cnt on the stack (Andrii Nakryiko)
> >
> > v3:
> > * refine SIZEOF_BPF_LOCAL_STORAGE_ELEM comment (Yonghong Song)
> > * anonymous struct in percpu_net_cnt & net_cnt (Yonghong Song)
> > * reorder free (Yonghong Song)
> >
> > v2:
> > * cap max_value_size instead of BUILD_BUG_ON (Martin KaFai Lau)
> >
> > Cc: Martin KaFai Lau <kafai@fb.com>
> > Cc: Yonghong Song <yhs@fb.com>
> > Cc: Andrii Nakryiko <andrii@kernel.org>
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---

> Added Martin's ack and applied to bpf-next. Please carry over received
> Acks between revisions.
Ah, sorry, forgot about it :-(

> It's also a good practice to separate selftest from the kernel (or
> libbpf) changes, unless kernel change doesn't immediately break
> selftest. Please consider doing that for the future.
I've actually seen some back and forth on this one. I used to split
them in the past (assuming it makes it easy to do the
backports/cherry-picks), but I remember at some point it was
suggested not to split them for small changes like this.

Might be a good idea to document this (when and if to separate  
libbpf/selftests)
on bpf_devel_QA.rst

> I also just noticed that test_netcnt isn't part of test_progs. It
> would be great to migrate it under the common test_progs
> infrastructure. We've been steadily moving towards that, but there are
> still a bunch of tests that are not run in CI.
SG, I might do a follow up on this one.