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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 08558C2D0A3 for ; Wed, 4 Nov 2020 23:06:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A5D5520786 for ; Wed, 4 Nov 2020 23:06:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728784AbgKDXGG (ORCPT ); Wed, 4 Nov 2020 18:06:06 -0500 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:55764 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728301AbgKDXGG (ORCPT ); Wed, 4 Nov 2020 18:06:06 -0500 Received: from dispatch1-us1.ppe-hosted.com (localhost.localdomain [127.0.0.1]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id B6C54A33D9 for ; Wed, 4 Nov 2020 23:05:56 +0000 (UTC) Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.61]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id EA0C2600BD; Wed, 4 Nov 2020 23:05:55 +0000 (UTC) Received: from us4-mdac16-23.ut7.mdlocal (unknown [10.7.65.247]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id E66188009E; Wed, 4 Nov 2020 23:05:55 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.90]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 6628B8006A; Wed, 4 Nov 2020 23:05:55 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id F03729C005E; Wed, 4 Nov 2020 23:05:54 +0000 (UTC) Received: from [10.17.20.203] (10.17.20.203) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Nov 2020 23:05:44 +0000 Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support To: Alexei Starovoitov CC: Hangbin Liu , David Ahern , "Daniel Borkmann" , Andrii Nakryiko , Stephen Hemminger , Alexei Starovoitov , Martin KaFai Lau , "Song Liu" , Yonghong Song , David Miller , Jesper Dangaard Brouer , Networking , bpf , Jiri Benc , Andrii Nakryiko , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= References: <20201028132529.3763875-1-haliu@redhat.com> <20201029151146.3810859-1-haliu@redhat.com> <646cdfd9-5d6a-730d-7b46-f2b13f9e9a41@gmail.com> <3306d19c-346d-fcbc-bd48-f141db26a2aa@gmail.com> <71af5d23-2303-d507-39b5-833dd6ea6a10@gmail.com> <20201103225554.pjyuuhdklj5idk3u@ast-mbp.dhcp.thefacebook.com> <20201104021730.GK2408@dhcp-12-153.nay.redhat.com> <20201104031145.nmtggnzomfee4fma@ast-mbp.dhcp.thefacebook.com> From: Edward Cree Message-ID: <07f149f6-f8ac-96b9-350d-b289ef16d82f@solarflare.com> Date: Wed, 4 Nov 2020 23:05:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.203] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-25766.003 X-TM-AS-Result: No-1.515600-8.000000-10 X-TMASE-MatchedRID: Jm7Yxmmj9OnmLzc6AOD8DfHkpkyUphL9WDtrCb/B2hARGC0rW8q1Xa2k qu8N8Z6gjbUqhuP4DgE/a3iI4EhF3zy85MOgqDd3GctYiGlVjB/ahA35D/bWBFp3Ei6xxmePXvb V/VnUv0qcdgImt2fnOLC8HNjVMLYUFOKk4UrUPgXmXEF3MwNZbn2K69afcnwqVWQnHKxp38ihcU SGWPyoCQPfHajKM2sCBaafuX8ZUps1mB4DwaTV1qOknopQLzTu8qeI5MA2SKR727cs+BZZRrcwZ LpPFTtAaOBJAM+wLRw4LxgJSVfCdYFLOlyz97WhNDrSVZCgbSumUoJ5iJZBr7EtLGRAe3PGesS+ g/Zq0C76DxBeqeXlOqqWalXMgUb91zJTsMOHLjrnVHXBUzVvZNBQpvv5cj0gJJjt/ngrkz8k1mQ 4C5BObp6fbj1zw/ix2CZ7T0FVcRTFVSBMr2cm9MzSKGx9g8xhywXStpqWmJZ7eGs179ltWZ5wam ltgCNJm+k82PC+tGTRMuzjTM1Wt8RBLZ5x+SkXngIgpj8eDcByZ8zcONpAscRB0bsfrpPIcSqbx BgG0w7KpO6qO1dZZL39VMPFRmMT0r4EyuzY7XFNEE+ml4S71fDzwTlmVMdjuO8r3cBqcThWu9cr rsVGVRk8KNSxhtI48LUy05gu3pDUNewp4E2/TgSpmVYGQlZ3sxk1kV1Ja8fhIo573pBCBw== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--1.515600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-25766.003 X-MDID: 1604531155-b2pbJnnWe2I2 X-PPE-DISP: 1604531155;b2pbJnnWe2I2 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 04/11/2020 22:10, Alexei Starovoitov wrote: > On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote: >> On 04/11/2020 03:11, Alexei Starovoitov wrote: >>> The user will do 'tc -V'. Does version mean anything from bpf loading pov? >>> It's not. The user will do "ldd `which tc`" and then what? >> Is it beyond the wit of man for 'tc -V' to output somethingabout >> libbpf version? >> Other libraries seem to solve these problems all the time, I >> haven't seen anyone explain what makes libbpf so special that it >> has to be different. > slow vger? Please see Daniel and Andrii detailed explanations. Nah, I've seen that subthread(vger is fine).  I felt that subthread  was missing this point about -V which is why I replied where it was  brought up. Daniel and Andrii have only explained why users will want to have an  up-to-date libbpf, they (and you) haven't connected it to any  argument about why static linking is the way to achieve that. > libbpf is not your traditional library. This has only been asserted, not explained. I'm fully willing to entertain the possibility that libbpf is indeed  special.  But if you want to win people over, you'll need to  explain *why* it's special. "Look at bfd and think why" is not enough, be more explicit. AIUI the API between iproute2 and libbpf isn't changing, all that's  happening is that libbpf is gaining new capabilities in things that  are totally transparent to iproute2 (e.g. BTF fixups).  So the  reasonable thing for users to expect is "I need new BPF features,  I'll upgrade my libbpf", and with dynamic linking that works fine  whether they upgrade iproute2 too or not. This narrative is, on the face of it, just as plausible as "I'm  getting an error from iproute2, I'll upgrade that".  And if distros  decide that that's a common enough mistake to matter, then they can  make the newer iproute2 package depend on a newer libbpf package,  and apt or yum or whatever will automagically DTRT. Whereas if you tightly couple them from the start, distros can't  then go the other way if it turns out you made the wrong choice.  (What if someone can't use the latest iproute2 release because it  has a regression bug that breaks their use-case, but they need the  latest libbpf for one of your shiny new features?) Don't get me wrong, I'd love a world in which static linking was the  norm and we all rebuilt our binaries locally every time we upgraded  a piece.  But that's not the world we live in, and consistency  *within* a distro matters too... -ed