From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 149FCC4338F for ; Tue, 27 Jul 2021 23:48:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB06260F4F for ; Tue, 27 Jul 2021 23:48:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232814AbhG0Xsp (ORCPT ); Tue, 27 Jul 2021 19:48:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232766AbhG0Xsp (ORCPT ); Tue, 27 Jul 2021 19:48:45 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98271C061757; Tue, 27 Jul 2021 16:48:43 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id w17so835581ybl.11; Tue, 27 Jul 2021 16:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jPRgbtGS6Pk9frO0T63mWMz81DzPxMuuTkI6I2qFqkE=; b=Sf47/z3aiSLPyOftcCo2FmqTsmfyQR1RUOgoKIoZwkLdx5Q75xOhmJfo8BI6Vh3jQ1 meiWGIJkK1Q/ZaT9B/8+5K/xT6xa/X2knk6uuHzy6laZuALLVNYn9BKNssZNWd6lM7BN KIfnf43CInjP21hwtjsOOYw9+9ZydeLafVnVD7am+TUiHITvHckh5ZEgrY/8ypXZmJQd N/Y7mma9oxKjoWa7MXqdGwFQKxpFul+BNskHnzdl7DBzQG9lr217nLCz/lURFbyWl+fu dQ90TPqC9WM6ochWbr/4rdMp/LvIuOwnFhO2Jtd7ntXWmYYnE9iv7o8ptMzBj22FZrTV 6IOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jPRgbtGS6Pk9frO0T63mWMz81DzPxMuuTkI6I2qFqkE=; b=HxmAU3QzWVi0n7qLF878adXQRgMwtquQdc5kKy9jCzVOAevhO73yNpMYVJnKtOXiwH b2OSWb+MlcalGPf5RiQ2IwQxCQtUaqqO2ZGJqVRAYfglPAUTcfjFX24+TMlIAoK1pddO 10NzFRT2ZVA2/XwKhZJrUJ3IjUcMXN3xt/5xLN9/ng4nMFqbd/6I24CDjvEK2y/ObPP0 ctrgy9FBt4aVSq+JvXY9XhdFlLX26gIFi1adNUgpII2u0m1Kuo+SoDVoYSNGQZGLFGl8 w3KH8rwbve9lLanNdjPp+4kyRwiMM6x4kCgEHcQa1w7jRWzvR0rU5m0f5nGF0tabB7Yc g9NQ== X-Gm-Message-State: AOAM533ckOuaC6QpXSB5iTpMT1u5p/7PlBCZvN/hP+GECqXAHgTSnU3/ trB3eb8GAnKSRtgkS1SMZAURrrwa+oDwOovZ2P4= X-Google-Smtp-Source: ABdhPJwSRcZQaSjVxUkwcOaUXHLCCfEqSleQTztCc/umt6maWUz1l2z3+XL6u1Vlz9T9EOOM3bINd6ZNi1XvvUiRLts= X-Received: by 2002:a25:9942:: with SMTP id n2mr34957355ybo.230.1627429722884; Tue, 27 Jul 2021 16:48:42 -0700 (PDT) MIME-Version: 1.0 References: <20210727222335.4029096-1-sdf@google.com> In-Reply-To: From: Andrii Nakryiko Date: Tue, 27 Jul 2021 16:48:31 -0700 Message-ID: Subject: Re: [PATCH bpf-next v4] bpf: increase supported cgroup storage value size To: Stanislav Fomichev Cc: Networking , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Yonghong Song Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Jul 27, 2021 at 4:25 PM wrote: > > On 07/27, Andrii Nakryiko wrote: > > On Tue, Jul 27, 2021 at 3:23 PM Stanislav Fomichev 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 > > > Cc: Yonghong Song > > > Cc: Andrii Nakryiko > > > Signed-off-by: Stanislav Fomichev > > > --- > > > 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. So we asked to split UAPI header sync for tools/include/ into a separate patch initially. But then I just improved libbpf's sync script to handle that regardless and we stopped asking for that. But the libbpf vs kernel vs selftests split was always (perhaps implicitly) advised. Personally, I've only had a few cases where selftest changes had to go in with kernel changes in the same patch to avoid breaking selftests. In all other cases it's cleaner to have them split out. > > 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. Sounds good, thanks!