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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 7ECD7ECE58C for ; Mon, 7 Oct 2019 17:12:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 52B2E206C0 for ; Mon, 7 Oct 2019 17:12:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="ylpNkZLT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729069AbfJGRMu (ORCPT ); Mon, 7 Oct 2019 13:12:50 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:43553 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729067AbfJGRMt (ORCPT ); Mon, 7 Oct 2019 13:12:49 -0400 Received: by mail-oi1-f196.google.com with SMTP id t84so12308902oih.10 for ; Mon, 07 Oct 2019 10:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=voxQqlXcqJ7mOo4KVvha7FaxVVFvUMitFdHwmuWnFVE=; b=ylpNkZLTfv7jeQ1uzPQDjIlQb6tJXjGs1GaCB6dQH2B7VIscYPzQRG0T6AWuvQcAwX UaYkok+r0Uct6mz8WKCK+drL+zFhLmfLLp0NwzSz7cb5q2uwYEArsL0/TqYuP3fg6QIE lnjKbp0c96AZT4oxE9Etvd2re8yMC7bWAIymA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=voxQqlXcqJ7mOo4KVvha7FaxVVFvUMitFdHwmuWnFVE=; b=hduluiLByCqSs64SNrqbGXh+kMp9qyZModr45fSPJ0r5lWzHrCv3K5qKdl+jlXnCat SwfJD0R6vJu2mtsvSJEe1IQyB69j58dFPK5X+GgorIOZAZTwqR64mtOAly+gO3f0vjoX ez2PjDO8q1U13Utvy2tnNBlQMdSxO8o8/9hy9KKxaIARfNIpuFoEhwIMdheQbGFLgUui 3lT4gLzPd0G3r5ZGvghJGaHv4qMuZAeMwh/sh/kyhwP/KDPhGRcjYQaIlv0tGMXdX/Ia lB81Tv9OmFT8y58P9ZDgVn60826WZF8hlDHfFbEdcQQln6xUsHNq83DEgEchMN0cu1sh /IWA== X-Gm-Message-State: APjAAAWtbL3fA1oyWwo9jjlcSdfeFVWhms08KW3sPv7uMkDzcN+Z+M8i KexHEkOzHKM3V1+dt+MQH9YAchd1wLpmYmPPulXEmndA X-Google-Smtp-Source: APXvYqxPJygoEvkl+rxpN2s9Nqb7Ree9yYY3K/Q5BCmPM8737XcrtX6MRYflZavuy2uNqaV0MkJ838fwSme1B8cSAug= X-Received: by 2002:aca:4f46:: with SMTP id d67mr286443oib.102.1570468368804; Mon, 07 Oct 2019 10:12:48 -0700 (PDT) MIME-Version: 1.0 References: <157002302448.1302756.5727756706334050763.stgit@alrua-x1> <87r23vq79z.fsf@toke.dk> <20191003105335.3cc65226@carbon> <87pnjdq4pi.fsf@toke.dk> <1c9b72f9-1b61-d89a-49a4-e0b8eead853d@solarflare.com> <5d964d8ccfd90_55732aec43fe05c47b@john-XPS-13-9370.notmuch> <87tv8pnd9c.fsf@toke.dk> <68466316-c796-7808-6932-01d9d8c0a40b@solarflare.com> <1871cacb-4a43-f906-9a9b-ba6a2ca866dd@solarflare.com> In-Reply-To: <1871cacb-4a43-f906-9a9b-ba6a2ca866dd@solarflare.com> From: Lorenz Bauer Date: Mon, 7 Oct 2019 18:12:37 +0100 Message-ID: Subject: Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through chain calls To: Edward Cree Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , John Fastabend , Alexei Starovoitov , Jesper Dangaard Brouer , Song Liu , Daniel Borkmann , Alexei Starovoitov , Martin Lau , Yonghong Song , Marek Majkowski , David Miller , "netdev@vger.kernel.org" , "bpf@vger.kernel.org" , kernel-team 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 On Mon, 7 Oct 2019 at 17:43, Edward Cree wrote: > > I might be being na=C3=AFve, but it doesn't sound more painful than is no= rmal > for userland. I mean, what operations have you got- > * create/destroy map (maybe, see above) > * load prog (pass it an fd from which it can read an ELF, and more fds > for the maps it uses. Everything else, e.g. BTFs, can just live in the > ELF.) > * destroy prog > * bind prog to hook (admittedly there's a long list of hooks, but this is > only to cover the XDP ones, so basically we just have to specify > interface and generic/driver/hw) > -that doesn't seem like it presents great difficulties? Sure, but this is the simplest, not necessarily realistic use case. There is a reason that libbpf has the API it has. For example, we patch our eBPF before loading it. I'm sure there are other complications, which is why I prefer to keep loading my own programs. > No, I'm talking about doing a linker step (using the 'full-blown calls' > _within_ an eBPF program that Alexei added a few months back) before the > program is submitted to the kernel. So the BPF_CALL|BPF_PSEUDO_CALL ins= n > gets JITed to a direct call. Ah, I see. I'm not sure whether this restriction has been lifted, but those calls are incompatible with tail calls. So we wouldn't be able to use this. > OK, but in that case xdpd isn't evidence that the "loader" approach doesn= 't > work, so I still think it should be tried before we go to the lengths of > pushing something into the kernel (that we then have to maintain forever= ). Maybe this came across the wrong way, I never said it is. Merely that it's the status quo we'd like to move away from. If we can achieve that in userspace, great. Lorenz --=20 Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com