bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrey Ignatov <rdna@fb.com>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link
Date: Mon, 30 Mar 2020 17:32:22 -0700	[thread overview]
Message-ID: <20200331003222.gdc2qb5rmopphdxl@ast-mbp> (raw)
In-Reply-To: <cdd576be-8075-13a7-98ee-9bc9355a2437@gmail.com>

On Mon, Mar 30, 2020 at 05:43:52PM -0600, David Ahern wrote:
> On 3/30/20 4:50 PM, Alexei Starovoitov wrote:
> > On Mon, Mar 30, 2020 at 1:46 PM David Ahern <dsahern@gmail.com> wrote:
> >> release. As it stands it is a half-baked feature.
> > 
> > speaking of half-baked.
> > I think as it stands (even without link_query) it's already extremely
> > useful addition and doesn't take anything away from existing cgroup-bpf
> > and doesn't hinder observability. 'bpftool cgroup' works just fine.
> > So I've applied the set.
> > 
> > Even if it was half-baked it would still be applie-able.
> > Many features are developed over the course of multiple
> > kernel releases. Example: your nexthops, mptcp, bpf-lsm.
> > 
> 
> nexthops were not - refactoring in 1 release and the entire feature went
> in to 5.4. Large features / patch sets often must be spread across
> kernel versions because it is not humanly possible to send and review
> the patches.
> 
> This is not a large feature, and there is no reason for CREATE/UPDATE -
> a mere 4 patch set - to go in without something as essential as the
> QUERY for observability.

As I said 'bpftool cgroup' covers it. Observability is not reduced in any way.
Also there is Documentation/bpf/drgn.rst
Kernel is an open book. Just learn this simple tool and everything will
be observable. Not only bpf objects, but the rest of the kernel too.
imo the use case for LINK_QUERY makes sense for xdp only.
There is one program there and it's a dispatcher program that libdispatcher
will be iteratively updating via freplace. For cgroup bpf_links I cannot
think of a reason why apps would need to query it.

  reply	other threads:[~2020-03-31  0:32 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  2:59 [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link Andrii Nakryiko
2020-03-30  2:59 ` [PATCH v3 bpf-next 1/4] bpf: implement bpf_link-based cgroup BPF program attachment Andrii Nakryiko
2020-03-31  0:05   ` Andrey Ignatov
2020-03-31  0:38     ` Alexei Starovoitov
2020-03-31  1:06       ` Andrii Nakryiko
2020-03-30  2:59 ` [PATCH v3 bpf-next 2/4] bpf: implement bpf_prog replacement for an active bpf_cgroup_link Andrii Nakryiko
2020-03-30  3:00 ` [PATCH v3 bpf-next 3/4] libbpf: add support for bpf_link-based cgroup attachment Andrii Nakryiko
2020-03-30  3:00 ` [PATCH v3 bpf-next 4/4] selftests/bpf: test FD-based " Andrii Nakryiko
2020-03-30 14:49 ` [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link David Ahern
2020-03-30 20:20   ` Andrii Nakryiko
2020-03-30 20:45     ` David Ahern
2020-03-30 20:50       ` Alexei Starovoitov
2020-03-30 22:50       ` Alexei Starovoitov
2020-03-30 23:43         ` David Ahern
2020-03-31  0:32           ` Alexei Starovoitov [this message]
2020-03-31  0:57             ` David Ahern
2020-03-31  1:17               ` Alexei Starovoitov
2020-04-01  1:42                 ` David Ahern
2020-04-01  2:04                   ` Alexei Starovoitov
2020-03-31  3:54               ` Andrii Nakryiko
2020-03-31 16:54                 ` David Ahern
2020-03-31 17:03                   ` Andrii Nakryiko
2020-03-31 17:11                   ` Alexei Starovoitov
2020-03-31 21:51                 ` Edward Cree
2020-03-31 22:44                   ` David Ahern
2020-04-01  0:45                     ` Andrii Nakryiko
2020-04-01  0:22                   ` Andrii Nakryiko
2020-04-01 14:26                     ` Edward Cree
2020-04-01 17:39                       ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200331003222.gdc2qb5rmopphdxl@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).