Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link
From: Alexei Starovoitov <hidden>
Date: 2020-03-31 00:32:30
Also in:
bpf
On Mon, Mar 30, 2020 at 05:43:52PM -0600, David Ahern wrote:
On 3/30/20 4:50 PM, Alexei Starovoitov wrote:quoted
On Mon, Mar 30, 2020 at 1:46 PM David Ahern [off-list ref] wrote:quoted
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.