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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 67BD8C35247 for ; Tue, 4 Feb 2020 19:19:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 36F772087E for ; Tue, 4 Feb 2020 19:19:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="EDbHNmG9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727358AbgBDTTd (ORCPT ); Tue, 4 Feb 2020 14:19:33 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:28284 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727442AbgBDTTd (ORCPT ); Tue, 4 Feb 2020 14:19:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580843972; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k0pjhqQ38lLEsOHy4AcSgtj8v6zTX3VHqcHQyJnlSjY=; b=EDbHNmG9ar1hS4xlFZ9ugxBuZ1PKELpVMEXSiz56JJrSjC8fJibtge0Sf1PWQ3n3X67YL4 e8u39MapBVUU08rvWiTpXfMlWseTZBe5eIQOSXMMiLqhaVp94XAhalqjCCREtZEEd1aNn3 8CHIe44AoHxIqw38l2o2alpcfilnPHY= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-55-ZpbZ3__TM5CIeNayFvn4FQ-1; Tue, 04 Feb 2020 14:19:28 -0500 X-MC-Unique: ZpbZ3__TM5CIeNayFvn4FQ-1 Received: by mail-lf1-f71.google.com with SMTP id c16so2657155lfm.10 for ; Tue, 04 Feb 2020 11:19:28 -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:content-transfer-encoding; bh=k0pjhqQ38lLEsOHy4AcSgtj8v6zTX3VHqcHQyJnlSjY=; b=T3OP+uesA1jFBE4izFBG+hC3kFNBv11u4oO7tR4eWDftzGPHsjJfp+iVS9RSREO5ea s7L+ZwlOidj6jlAxvElMRjj+R4hX4fyfY2E0weAKaDIz9QypvVxIO0ETqtY6tXQvte+9 0nowfV35sdiwlQbgKIPU2soOVhI+zh1Gqfd6htgLoDRn+yHCC0TtfPqM6g6uK6R4G4Kh +taaaVJ2sBzqaxYSPI7BrP1MSBRGfFRZ3hzvj2p2NMZgelEoPmJgg7CFUjJH6tnUoBUx bpYKX7O5l3CqIM0nHEGeIAGHq07l34+4mv5STZioarE0I8qk4qH9vNfUfyB1in2fKrTK 46/Q== X-Gm-Message-State: APjAAAURAmc0SrUf+A5jjpxiwCVZOfYLPc6U/m1fazJI0vt78emjm+Ay FXzIG2JqtL3GOsM5ZcjD1Zq7JcSd8KmcXl6p/iLTNbJR1HF9C3MFV0AO2oHs+ShSYPi1bAE8C0q xQ3DZgNBXfcGN X-Received: by 2002:a2e:a404:: with SMTP id p4mr18722646ljn.234.1580843967224; Tue, 04 Feb 2020 11:19:27 -0800 (PST) X-Google-Smtp-Source: APXvYqzjvtMf2bfhzg268ZEIuVd0j8Vz7vTbbgj1be3aFsRivKNgBMLzW1BZjWry/ZTV+Ze1XTav7A== X-Received: by 2002:a2e:a404:: with SMTP id p4mr18722636ljn.234.1580843966957; Tue, 04 Feb 2020 11:19:26 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id t1sm12167127lji.98.2020.02.04.11.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2020 11:19:26 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 60B0D1802D4; Tue, 4 Feb 2020 20:19:23 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Andrii Nakryiko Cc: David Ahern , Daniel Borkmann , Stephen Hemminger , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , David Miller , Jesper Dangaard Brouer , Networking , bpf Subject: Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP) In-Reply-To: References: <20190820114706.18546-1-toke@redhat.com> <87blwiqlc8.fsf@toke.dk> <43e8c177-cc9c-ca0b-1622-e30a7a1281b7@iogearbox.net> <87tva8m85t.fsf@toke.dk> <87blqfcvnf.fsf@toke.dk> <0bf50b22-a8e2-e3b3-aa53-7bd5dd5d4399@gmail.com> <2cf136a4-7f0e-f4b7-1ecb-6cbf6cb6c8ff@gmail.com> <87h80669o6.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 04 Feb 2020 20:19:23 +0100 Message-ID: <8736bqf9dw.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Andrii Nakryiko writes: > On Tue, Feb 4, 2020 at 12:25 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Andrii Nakryiko writes: >> >> > On Mon, Feb 3, 2020 at 8:53 PM David Ahern wrote: >> >> >> >> On 2/3/20 8:41 PM, Andrii Nakryiko wrote: >> >> > On Mon, Feb 3, 2020 at 5:46 PM David Ahern wrot= e: >> >> >> >> >> >> On 2/3/20 5:56 PM, Andrii Nakryiko wrote: >> >> >>> Great! Just to disambiguate and make sure we are in agreement, my= hope >> >> >>> here is that iproute2 can completely delegate to libbpf all the E= LF >> >> >>> >> >> >> >> >> >> iproute2 needs to compile and continue working as is when libbpf i= s not >> >> >> available. e.g., add check in configure to define HAVE_LIBBPF and = move >> >> >> the existing code and move under else branch. >> >> > >> >> > Wouldn't it be better to statically compile against libbpf in this >> >> > case and get rid a lot of BPF-related code and simplify the rest of >> >> > it? This can be easily done by using libbpf through submodule, the >> >> > same way as BCC and pahole do it. >> >> > >> >> >> >> iproute2 compiles today and runs on older distributions and older >> >> distributions with newer kernels. That needs to hold true after the m= ove >> >> to libbpf. >> > >> > And by statically compiling against libbpf, checked out as a >> > submodule, that will still hold true, wouldn't it? Or there is some >> > complications I'm missing? Libbpf is designed to handle old kernels >> > with no problems. >> >> My plan was to use the same configure test I'm using for xdp-tools >> (where I in turn copied the structure of the configure script from >> iproute2): >> >> https://github.com/xdp-project/xdp-tools/blob/master/configure#L59 >> >> This will look for a system libbpf install and compile against it if it >> is compatible, and otherwise fall back to a statically linking against a >> git submodule. > > How will this work when build host has libbpf installed, but target > host doesn't? You'll get dynamic linker error when trying to run that > tool. That's called dependency tracking; distros have various ways of going about that :) But yeah, if you're going to do you own cross-compilation, you'd probably want to just force using the static library. > If the goal is to have a reliable tool working everywhere, and you > already support having libbpf as a submodule, why not always use > submodule's libbpf? What's the concern? Libbpf is a small library, I > don't think a binary size argument is enough reason to not do this. On > the other hand, by using libbpf from submodule, your tool is built > *and tested* with a well-known libbpf version that tool-producer > controls. I thought we already had this discussion? :) libbpf is a library like any other. Distros that package the library want the tools that use it to be dynamically linked against it so library upgrades (especially of the CVE-fixing kind) get picked up by all users. Other distros have memory and space constraints (iproute2 is shipped on OpenWrt, for instance, which is *extremely* space-constrained). And yeah, other deployments don't care and will just statically compile in the vendored version. So we'll need to support all of those use cases. -Toke