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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 0596AC4741F for ; Fri, 6 Nov 2020 23:25:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A585A206CB for ; Fri, 6 Nov 2020 23:25:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="kRaxAGDo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728245AbgKFXZs (ORCPT ); Fri, 6 Nov 2020 18:25:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727859AbgKFXZs (ORCPT ); Fri, 6 Nov 2020 18:25:48 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02466C0613D2 for ; Fri, 6 Nov 2020 15:25:46 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id y7so2824161pfq.11 for ; Fri, 06 Nov 2020 15:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=t49Uj56W+rkBFWbXc8EIUZI8P2qyJdCmrkeESNJo37k=; b=kRaxAGDoYIbKFnS8WRSV3cm99v/TilSAJfBqHjzxZmqFHbEsLzkzyzj7X/s0BQhbr+ l2XwCCXWCRlR0ddiM563blEHGyGnJkQStMQ0gYtmhLKjY8zKUf0hjEJklu8nS7cK7AAj AjfR1b/Cz9UIlt2/v8Vv/ZLdsatc+M4rz3tFjA/En8x0+2EvYpph9mGX+OxS1+iei7bY m6Zaz5+8W7J2VVcBs9wm6gfGLyq95N+j32I4uNwf/1DTVvCKGtvsPAUy/mESF9j/TMlf pbvMwxgxymXxnUC0pC2epJmgAUlPj4xOeyHbiZfe0W0pOc9q1ZMFT2w4Mi5JDmRb+kd4 RjGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=t49Uj56W+rkBFWbXc8EIUZI8P2qyJdCmrkeESNJo37k=; b=SlbzuEkCS2B9GQzHFj+67ZqE0ajknLdISjyE1/YCxDTRLwBcXPOsppbRuw9cNH0UhR EeR3ujBtwseGvX6gVIzLdf2L3QFth/KP5yzXc5P7/DCdEc0KBPw+VJgsJrXi0taG7vou hE2YiN4iNMuqkRwu9ifBi1Dz9GZ+iJR7WdS0DWWzRSp9DL9k2PjBQQN8kCLdbCN0fHLZ 9jFgDDY6TJ28IdUJ1tOjKYO4fG5AL7QxZKxdbPIt8o6pQMP3wwtdUUMH+yT40uGt5IWL VBY7s09YYuqwJ0M1emxvYDHCZhBZy4xNwKKvtUTIZLaUM1byUKlJHqAUH57+8huRKGW3 P1/Q== X-Gm-Message-State: AOAM53192GJBTNDnCJxUld9n2RJvWXJefGM60csfjogQrPn4cBEz3bxi 9aeaUp+qWMD9H+TeeI4ZQE4dxw== X-Google-Smtp-Source: ABdhPJyDt7ziyRq5YmjNNtmJtSQPmeQPIXjp4Pa4UewTKU2XTFtyAAzPHuBjDx6UNUeIS+UWguxj4g== X-Received: by 2002:a17:90b:a05:: with SMTP id gg5mr1914882pjb.214.1604705146479; Fri, 06 Nov 2020 15:25:46 -0800 (PST) Received: from hermes.local (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id i13sm2140894pfo.139.2020.11.06.15.25.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Nov 2020 15:25:46 -0800 (PST) Date: Fri, 6 Nov 2020 15:25:37 -0800 From: Stephen Hemminger To: Alexei Starovoitov Cc: Andrii Nakryiko , Jiri Benc , Edward Cree , Hangbin Liu , David Ahern , Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , David Miller , Jesper Dangaard Brouer , Networking , bpf , Andrii Nakryiko , Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support Message-ID: <20201106152537.53737086@hermes.local> In-Reply-To: References: <20201028132529.3763875-1-haliu@redhat.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> <07f149f6-f8ac-96b9-350d-b289ef16d82f@solarflare.com> <20201106094425.5cc49609@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 6 Nov 2020 13:04:16 -0800 Alexei Starovoitov wrote: > On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko > wrote: > > > > On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc wrote: > > > > > > On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote: > > > > I'll just quote myself here for your convenience. > > > > > > Sorry, I missed your original email for some reason. > > > > > > > Submodule is a way that I know of to make this better for end users. > > > > If there are other ways to pull this off with shared library use, I'm > > > > all for it, it will save the security angle that distros are arguing > > > > for. E.g., if distributions will always have the latest libbpf > > > > available almost as soon as it's cut upstream *and* new iproute2 > > > > versions enforce the latest libbpf when they are packaged/released, > > > > then this might work equivalently for end users. If Linux distros > > > > would be willing to do this faithfully and promptly, I have no > > > > objections whatsoever. Because all that matters is BPF end user > > > > experience, as Daniel explained above. > > > > > > That's basically what we already do, for both Fedora and RHEL. > > > > > > Of course, it follows the distro release cycle, i.e. no version > > > upgrades - or very limited ones - during lifetime of a particular > > > release. But that would not be different if libbpf was bundled in > > > individual projects. > > > > Alright. Hopefully this would be sufficient in practice. > > I think bumping the minimal version of libbpf with every iproute2 release > is necessary as well. > Today iproute2-next should require 0.2.0. The cycle after it should be 0.3.0 > and so on. > This way at least some correlation between iproute2 and libbpf will be > established. > Otherwise it's a mess of versions and functionality from user point of view. As long as iproute2 6.0 and libbpf 0.11.0 continues to work on older kernel (like oldest living LTS 4.19 in 2023?); then it is fine. Just don't want libbpf to cause visible breakage for users.