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=-0.8 required=3.0 tests=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 8D5E3C3A5A1 for ; Wed, 21 Aug 2019 21:07:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6BC1222CF7 for ; Wed, 21 Aug 2019 21:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730721AbfHUVHH convert rfc822-to-8bit (ORCPT ); Wed, 21 Aug 2019 17:07:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56014 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726828AbfHUVHH (ORCPT ); Wed, 21 Aug 2019 17:07:07 -0400 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 73EABC0546FE for ; Wed, 21 Aug 2019 21:07:06 +0000 (UTC) Received: by mail-ed1-f71.google.com with SMTP id f11so2086000edb.16 for ; Wed, 21 Aug 2019 14:07:06 -0700 (PDT) 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=+7oLCOeDF3XQIliJ9uRMKaUP7ACTfu+YJIQN3Ry6XhE=; b=dfLrxhA5IM5lk25xfJHd/ErxUgSqQOtJSLPv1l8knbB5jkIUVK3LdAH1Bm9QtlM1Zv ek2fZMbXnGMAhkptZaZ+Xkci+lFdoej8RzOyIH1j6coNllBXN2CsKIVFdCag31HMoYxS N9+AnCmxIx6KtyfY1fALEg1GfFunz9R5wkoh+ZPmjQdbladSWoGkB7WoTw5q2spQKJAF rNde0eo6dJdFxuo87RvGRkjhWxa6QKHuLyfcHoI8ZaYJoCejn9IEoZMObk19Xyr/tAY/ UPfPkpFdQaOm3ZMAMl60it3eQYeCrzD6+U/nIZuIP7nGUGykowlNMvNxaY6iRuKzS2ML cnjQ== X-Gm-Message-State: APjAAAWTvDdf3JZ8NZ/Qzk71aiL7H8MOgMH0oCzaEM3PB+cyMu7TPvEk UIGwOITIVSgAM36XwdwuYYSPdeJlaWTAQc3k3FWqefKuN30KwfXC/3zCRV0MPf0C5E+0gipMlse uLEKc2vfk3qI62VDk X-Received: by 2002:a05:6402:8c9:: with SMTP id d9mr38353378edz.154.1566421625246; Wed, 21 Aug 2019 14:07:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqzUY+iDRwRgKuCrfG9co2//nIesFJTWxGEP9ldqjNYDopMSqCNSsQT8NfZSjV1TXbVNUAiHxA== X-Received: by 2002:a05:6402:8c9:: with SMTP id d9mr38353362edz.154.1566421625088; Wed, 21 Aug 2019 14:07:05 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id r16sm3288626eji.71.2019.08.21.14.07.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2019 14:07:04 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id CB1E2181CEF; Wed, 21 Aug 2019 23:07:03 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Andrii Nakryiko Cc: Stephen Hemminger , Daniel Borkmann , 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 21 Aug 2019 23:07:03 +0200 Message-ID: <87blwiqlc8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Andrii Nakryiko writes: > On Tue, Aug 20, 2019 at 4:47 AM Toke Høiland-Jørgensen wrote: >> >> iproute2 uses its own bpf loader to load eBPF programs, which has >> evolved separately from libbpf. Since we are now standardising on >> libbpf, this becomes a problem as iproute2 is slowly accumulating >> feature incompatibilities with libbpf-based loaders. In particular, >> iproute2 has its own (expanded) version of the map definition struct, >> which makes it difficult to write programs that can be loaded with both >> custom loaders and iproute2. >> >> This series seeks to address this by converting iproute2 to using libbpf >> for all its bpf needs. This version is an early proof-of-concept RFC, to >> get some feedback on whether people think this is the right direction. >> >> What this series does is the following: >> >> - Updates the libbpf map definition struct to match that of iproute2 >> (patch 1). > > > Hi Toke, > > Thanks for taking a stab at unifying libbpf and iproute2 loaders. I'm > totally in support of making iproute2 use libbpf to load/initialize > BPF programs. But I'm against adding iproute2-specific fields to > libbpf's bpf_map_def definitions to support this. > > I've proposed the plan of extending libbpf's supported features so > that it can be used to load iproute2-style BPF programs earlier, > please see discussions in [0] and [1]. Yeah, I've seen that discussion, and agree that longer term this is probably a better way to do map-in-map definitions. However, I view your proposal as complementary to this series: we'll probably also want the BTF-based definition to work with iproute2, and that means iproute2 needs to be ported to libbpf. But iproute2 needs to be backwards compatible with the format it supports now, and, well, this series is the simplest way to achieve that IMO :) > I think instead of emulating iproute2 way of matching everything based > on user-specified internal IDs, which doesn't provide good user > experience and is quite easy to get wrong, we should support same > scenarios with better declarative syntax and in a less error-prone > way. I believe we can do that by relying on BTF more heavily (again, > please check some of my proposals in [0], [1], and discussion with > Daniel in those threads). It will feel more natural and be more > straightforward to follow. It would be great if you can lend a hand in > implementing pieces of that plan! > > I'm currently on vacation, so my availability is very sparse, but I'd > be happy to discuss this further, if need be. Happy to collaborate on your proposal when you're back from vacation; but as I said above, I believe this is a complementary longer-term thing... -Toke