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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6609DC433F5 for ; Tue, 10 May 2022 22:50:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229737AbiEJWuR (ORCPT ); Tue, 10 May 2022 18:50:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232630AbiEJWuN (ORCPT ); Tue, 10 May 2022 18:50:13 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CAEF724DC54 for ; Tue, 10 May 2022 15:50:11 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id kk28so621472qvb.3 for ; Tue, 10 May 2022 15:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5pgf2LC4mfZtxmKKitMud+Oy12RPGcU3F46iHWGsadA=; b=ekAQBJLQ0g2H+FUmFV5f70dwdMJlmpMe43UT4QIXA58jzQ7eDTurlQUHhbMjmFXgUn iSvHyXVOpjYMsk92HbvRZQl8ByOek4TmP4dutBYmWmysLSp+0lz8VY73TGj93QW0TK/I wFDu3nWggMxUUhT25DqnrpkQRHcZyfZQlsTbTl94c/g9RyI7z/yYTSrr78bkYPz4zPE6 iY4Bp9up41gXopOTZgVvz0svbTi1cJwop5wCmJ5rigsS40iOXz4jYN10Zh1qCwptI9S1 NrCYR94Zlax6XmK+bd61BAf+16YQeV+dhN2Bpph/aIHzuhFyMVqWf35ODyxRjEeOQHST hZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5pgf2LC4mfZtxmKKitMud+Oy12RPGcU3F46iHWGsadA=; b=QhtwVxJUJQ0ctE5z8Ln3Gs0AY7ySSi29RZnqrSvliWAyrsBP71JbCmwcQJLIamu+/3 J0gjnBev+WP9kRF0T7el+M+WgBnSARCmPTgPg5wjCpYNp9/vpZ608xS8O4u3AbsIV+zJ 15dFK/bC/1FBh0yiyzwILOkqAY5P46FGR1X5u6wock4xF/rYUnTc8xqrXcxHnYQyJpp2 k3rZhdqEb2h8X+FoFhWU0Y39dDaYlnOr9jevWLWFHxoju9xBSMguwLCzJgFuhS9Yg9ss 7WokX4nqG1rPoqH7z28YYmKof+aM9GQFVnM3Vo8lT3J+ILJn+N1jmKzhTM0x87b59c7i 1WAg== X-Gm-Message-State: AOAM533sefsjSe8QbCcBRznPIQ6b6zvKM/mZ68uyQGR0WEkQyOA+Z5K1 apenes4CDa4y+i0+gf6tBMfgzA+c4adMnjwS7K79dg== X-Google-Smtp-Source: ABdhPJzAFn9/jIPprW6IL+T0z4v5PPLX/63yNDyYNQ0qdZ3QxvFVYV7PhbjIoCNQF1WFZkNWMTKoVzPSeNUYybVJQSc= X-Received: by 2002:ad4:4753:0:b0:456:34db:614b with SMTP id c19-20020ad44753000000b0045634db614bmr19945189qvx.17.1652223010267; Tue, 10 May 2022 15:50:10 -0700 (PDT) MIME-Version: 1.0 References: <20220510001807.4132027-1-yosryahmed@google.com> <20220510001807.4132027-9-yosryahmed@google.com> In-Reply-To: From: Hao Luo Date: Tue, 10 May 2022 15:49:59 -0700 Message-ID: Subject: Re: [RFC PATCH bpf-next 8/9] bpf: Introduce cgroup iter To: Tejun Heo Cc: Yosry Ahmed , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Zefan Li , Johannes Weiner , Shuah Khan , Roman Gushchin , Michal Hocko , Stanislav Fomichev , David Rientjes , Greg Thelen , Shakeel Butt , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 3:07 PM Tejun Heo wrote: > > Hello, > > On Tue, May 10, 2022 at 02:12:16PM -0700, Hao Luo wrote: > > > Is there a reason why this can't be a proper iterator which supports > > > lseek64() to locate a specific cgroup? > > > > > > > There are two reasons: > > > > - Bpf_iter assumes no_llseek. I haven't looked closely on why this is > > so and whether we can add its support. > > > > - Second, the name 'iter' in this patch is misleading. What this patch > > really does is reusing the functionality of dumping in bpf_iter. > > 'Dumper' is a better name. We want to create one file in bpffs for > > each cgroup. We are essentially just iterating a set of one single > > element. > > I see. I'm just shooting in the dark without context but at least in > principle there's no reason why cgroups wouldn't be iterable, so it might be > something worth at least thinking about before baking in the interface. > Yep. Conceptually there should be no problem to iterate cgroups in the system. It may be better to have two independent bpf objects: bpf_iter and bpf_dumper. In our use case, we want bpf_dumper, which just exports data out through fs interface. Hao