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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 8FB8AC388F9 for ; Wed, 11 Nov 2020 11:02:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1FF4F20756 for ; Wed, 11 Nov 2020 11:02:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HdYebn0b" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725984AbgKKLCg (ORCPT ); Wed, 11 Nov 2020 06:02:36 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46063 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725959AbgKKLCf (ORCPT ); Wed, 11 Nov 2020 06:02:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605092554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HgnsptKYrAYETwb6RQgP12ipc3XlwLCSG6GxAjNNiQg=; b=HdYebn0bjIhjrD1RljpXkyCe3gqmj/Xge1/BecCBYojGzfm0xUKSj1Xqgk5TJEsCPZ153M Q19YUQfqg5L/K0FXNc/y5TSgsQKhLsc7439FDwStCJbJWgN+QosmB87WYQMsBuwmyV9N/1 HRUNQm7cPMsBh6EVVx52E7/tROnUVc0= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-583-RqlTmw6-NbSVMJGENgZcGg-1; Wed, 11 Nov 2020 06:02:32 -0500 X-MC-Unique: RqlTmw6-NbSVMJGENgZcGg-1 Received: by mail-qv1-f70.google.com with SMTP id c90so1131464qva.11 for ; Wed, 11 Nov 2020 03:02:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=HgnsptKYrAYETwb6RQgP12ipc3XlwLCSG6GxAjNNiQg=; b=htU6gGh60hetL0N51uZStfJ1LmUjl3VNWvsMKK1MZD1O7G/rx3n8blNlSRit1VMYPp pf/yXichwDOz8VzJjhZjUq0ojLz5jeEsgbFuMAWKGob+ZlHfl79XHQHeouE9GrR5Odk8 /NiskvHnlnLX0w2M6e05w22NBLHtV2qYAJkvnigdHz8nPMsJQ3DD2+++0I7kiUhPMWtz ekCuvzceYQYAGxv7WzkPrSxYvw4SNrwNfyv9TMPTYQqQgdUUXw7kt9UBpfPvq4eXO6mv Yml08YDWzgtkEbFaCaAKMygqFzEn3kq5b1oD/8E4XmDWggjPbcCRnrWUgDZStHotwP8F miuA== X-Gm-Message-State: AOAM532YL8R0+/1Lj7X2f+ePbjrGAexLTUuY4FzZ4jOd4u67Q8yCitH8 Nx1YM4NqcT18KMaovwIFwHrMmRAlRtTaXSiRVi+7lpBXM9kT2iY/OiMxZpXzvr/R/W/MVDLaus5 y6hkQAGIo6lpA X-Received: by 2002:ac8:1201:: with SMTP id x1mr12717913qti.339.1605092551561; Wed, 11 Nov 2020 03:02:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJzk553Y+qO9pY8i86H2Q8DT91q75yDtJJLXiQ9gewjey8d5E3lMiuoHYWNh9qdk7ow0cv4rww== X-Received: by 2002:ac8:1201:: with SMTP id x1mr12717886qti.339.1605092551320; Wed, 11 Nov 2020 03:02:31 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id s23sm1718122qke.11.2020.11.11.03.02.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Nov 2020 03:02:29 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id B1EAB1833E9; Wed, 11 Nov 2020 12:02:26 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Alexei Starovoitov , David Ahern Cc: Stephen Hemminger , Andrii Nakryiko , Jiri Benc , Edward Cree , Hangbin Liu , Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , David Miller , Jesper Dangaard Brouer , Networking , bpf , Andrii Nakryiko Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support In-Reply-To: <20201111004749.r37tqrhskrcxjhhx@ast-mbp> References: <07f149f6-f8ac-96b9-350d-b289ef16d82f@solarflare.com> <20201106094425.5cc49609@redhat.com> <20201106152537.53737086@hermes.local> <45d88ca7-b22a-a117-5743-b965ccd0db35@gmail.com> <20201109014515.rxz3uppztndbt33k@ast-mbp> <14c9e6da-e764-2e2c-bbbb-bc95992ed258@gmail.com> <20201111004749.r37tqrhskrcxjhhx@ast-mbp> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 11 Nov 2020 12:02:26 +0100 Message-ID: <874klwcg1p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Alexei Starovoitov writes: > On Mon, Nov 09, 2020 at 09:09:44PM -0700, David Ahern wrote: >> On 11/8/20 6:45 PM, Alexei Starovoitov wrote: >> > >> > I don't understand why on one side you're pointing out existing quirkiness with >> > bpf usability while at the same time arguing to make it _less_ user friendly >> >> I believe you have confused my comments with others. My comments have >> focused on one aspect: The insistence by BPF maintainers that all code >> bases and users constantly chase latest and greatest versions of >> relevant S/W to use BPF > > yes, because we care about user experience while you're still insisting > on make it horrible. > With random pick of libbpf.so we would have no choice, but to actively tell > users to avoid using tc, because sooner or later they will be pissed. I'd > rather warn them ahead of time. Could we *please* stop with this "my way or the highway" extortion? It's incredibly rude, and it's not helping the discussion. >> - though I believe a lot of the tool chasing >> stems from BTF. I am fairly certain I have been consistent in that theme >> within this thread. > > Right. A lot of features added in the last couple years depend on BTF: > static vs global linking, bpf_spin_lock, function by function verification, etc > >> > when myself, Daniel, Andrii explained in detail what libbpf does and how it >> > affects user experience? >> > >> > The analogy of libbpf in iproute2 and libbfd in gdb is that both libraries >> >> Your gdb / libbfd analogy misses the mark - by a lot. That analogy is >> relevant for bpftool, not iproute2. >> >> iproute2 can leverage libbpf for 3 or 4 tc modules and a few xdp hooks. >> That is it, and it is a tiny percentage of the functionality in the package. > > cat tools/lib/bpf/*.[hc]|wc -l > 23950 > cat iproute2/tc/*.[hc]|wc -l > 29542 > > The point is that for these few tc commands the amount logic in libbpf/tc is 90/10. > > Let's play it out how libbpf+tc is going to get developed moving forward if > libbpf is a random version. Say, there is a patch for libbpf that makes > iproute2 experience better. bpf maintainers would have no choice, but to reject > it, since we don't add features/apis to libbpf if there is no active user. > Adding a new libbpf api that iproute2 few years from now may or may not take > advantage makes little sense. What? No one has said that iproute2 would never use any new features, just that they would be added conditionally on a compatibility check with libbpf (like the check for bpf_program__section_name() in the current patch series). Besides, for the entire history of BPF support in iproute2 so far, the benefit has come from all the features that libbpf has just started automatically supporting on load (BTF, etc), so users would have benefited from automatic library updates had it *not* been vendored in. -Toke