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.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 A0917C63777 for ; Tue, 17 Nov 2020 02:38:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 385A42469D for ; Tue, 17 Nov 2020 02:38:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q3jbUvXt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727065AbgKQCiD (ORCPT ); Mon, 16 Nov 2020 21:38:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726771AbgKQCiB (ORCPT ); Mon, 16 Nov 2020 21:38:01 -0500 Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80E2CC0613CF; Mon, 16 Nov 2020 18:38:01 -0800 (PST) Received: by mail-pg1-x543.google.com with SMTP id v21so2273781pgi.2; Mon, 16 Nov 2020 18:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=G0DEGjjDiDmPveVipYJGdwwZdGpe8MZoy5sy/lp+AYk=; b=Q3jbUvXt1o/TZioJ69dwSqSViemWYwalrjEtjq6V00Ll26CxTS6m52rM4Ud11Yo45G F+nzur6SC5HVqkGE725YisV4bO6rwKNF19YrFAJRJguoFvpxL8fuQ3DmM1s6x8reJzzV QJ7wCPXdTvA6gVodrnZ21cAgj4EMCKtTt5DszsHMdlEVflFaSQQV5aqjypmKiJRaiKdI 6AI87YfYVV/35A4ym+iSY0ZR7NZNKoYz70VCWXUVdXFP/WjTFxDkoZ8xllclbZMO0+K6 aC/Ayq8N9xieycNoekjKiYZ5I/QS/jD9hp+U9iG3ubk14SnmLiLOSrM20CyNjYFwqgGa w7jw== 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:references :mime-version:content-disposition:in-reply-to; bh=G0DEGjjDiDmPveVipYJGdwwZdGpe8MZoy5sy/lp+AYk=; b=asVxN81LyMw7fvns9AW8AmikSfkUamhRjiYwFy6+lUrM0rw6YwyPwN/y7iiLb9tuQf 0J6/P+nHKxqEqzRpkEtL9pSqFmSQDZ3c2lSh3GcVPXVTEBB/8w8d++gvzImGO3OhK+D2 /BZbbM7yt5g58OSIsd3PDUNO0uot9A5yIfdC1LT0OHPsgorqqG8OWweVl4v/7aa7ke2p 6A76MC5qQm+kQVAkhHX7OzHYl6ozkYoqd2OsSPptNfCyaHUpmD7gw4cHtVPPuuGIo4Pl Q8z8SpJdDee5P5QBc4kCnq9IzJTzOzUUDc5vyIvQbCRoVGFJMsIv73RhTEmRdBc9KZpg oZyw== X-Gm-Message-State: AOAM530XDIU/A85/vR7CDnUiaJghpT3siZtSPI+GsLp9nWjHHKM/0ofF M3vubUU5ArdLXbGZ0tgOQ9w= X-Google-Smtp-Source: ABdhPJyIYstmthDQGzz23HPHktLu38SuvuyNa/62CpdWKhmjf0KY5VMgs5V6HGmjJYekZhriYlywcg== X-Received: by 2002:a63:5a62:: with SMTP id k34mr1769169pgm.391.1605580681003; Mon, 16 Nov 2020 18:38:01 -0800 (PST) Received: from ast-mbp ([2620:10d:c090:400::5:65f6]) by smtp.gmail.com with ESMTPSA id 64sm8798532pfe.0.2020.11.16.18.37.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 18:37:59 -0800 (PST) Date: Mon, 16 Nov 2020 18:37:57 -0800 From: Alexei Starovoitov To: Jesper Dangaard Brouer Cc: Hangbin Liu , Stephen Hemminger , David Ahern , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , David Miller , Network Development , bpf , Jiri Benc , Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: [PATCHv5 iproute2-next 0/5] iproute2: add libbpf support Message-ID: <20201117023757.qypmhucuws3sajyb@ast-mbp> References: <20201109070802.3638167-1-haliu@redhat.com> <20201116065305.1010651-1-haliu@redhat.com> <20201116155446.16fe46cf@carbon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201116155446.16fe46cf@carbon> Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, Nov 16, 2020 at 03:54:46PM +0100, Jesper Dangaard Brouer wrote: > > Thus, IMHO we MUST move forward and get started with converting > iproute2 to libbpf, and start on the work to deprecate the build in > BPF-ELF-loader. I would prefer ripping out the BPF-ELF-loader and > replace it with libbpf that handle the older binary elf-map layout, but > I do understand if you want to keep this around. (at least for the next > couple of releases). I don't understand why legacy code has to be around. Having the legacy code and an option to build tc without libbpf creates backward compatibility risk to tc users: Newer tc may not load bpf progs that older tc did. > I actually fear that it will be a bad user experience, when we start to > have multiple userspace tools that load BPF, but each is compiled and > statically linked with it own version of libbpf (with git submodule an > increasing number of tools will have more variations!). So far people either freeze bpftool that they use to load progs or they use libbpf directly in their applications. Any other way means that the application behavior will be unpredictable. If a company built a bpf-based product and wants to distibute such product as a package it needs a way to specify this dependency in pkg config. 'tc -V' is not something that can be put in a spec. The main iproute2 version can be used as a dependency, but it's meaningless when presence of libbpf and its version is not strictly derived from iproute2 spec. The users should be able to write in their spec: BuildRequires: iproute-tc >= 5.10 and be confident that tc will load the prog they've developed and tested. > I actually thinks it makes sense to have iproute2 require a specific > libbpf version, and also to move this version requirement forward, as > the kernel evolves features that gets added into libbpf. +1