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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7CB3FC43613 for ; Fri, 21 Jun 2019 10:29:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 523C621530 for ; Fri, 21 Jun 2019 10:29:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="Ggf5g8mV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726289AbfFUK3z (ORCPT ); Fri, 21 Jun 2019 06:29:55 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:35453 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726210AbfFUK3y (ORCPT ); Fri, 21 Jun 2019 06:29:54 -0400 Received: by mail-ot1-f68.google.com with SMTP id j19so5846137otq.2 for ; Fri, 21 Jun 2019 03:29:54 -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; bh=vABUrhDDlgLaEgsGYnr/fcBvwyUpWVTqO8p1TtDrOes=; b=Ggf5g8mV1RaLfhmi+55Hhcpvg4Cp6BH2/Tcn+fpGfUQ9h9LUe6rCX8Xbe3OPSigdTZ 4xm0uQHwoNTm1xtFSfocJXBGHywpv0VddCYw+YWFKvG9RGnsgrEny61YAo6vpBmxaONq kh9EaiVpkq4Ym4nj510rrp+CWDMtuDi2IzxmM= 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; bh=vABUrhDDlgLaEgsGYnr/fcBvwyUpWVTqO8p1TtDrOes=; b=oJneI5E5ec1QAIbB29J6+FS4rc8DZ5PxCjzmV4mMXYsUVQVNxAIo/4eEPP1kSnzR40 aT5lyKtsZLEtKnD4HnVNv365bnl6ARjR8EmdV0OFMSXNDDdTPd4AdAEj4758kv7lJyDA 4Ud437/i85hWRlgPKVzCM0egdH1Q8YIpEWmhM7ieMU6PY8X+aKpbpAp2G/MQ+tkWBSyN sbyJrSgP/hgb7YbQi4p/BLna68zJqRG2zIpNX/REWOn7pPllo0c0+pls4DYtQ4RvhDgZ vd0rGTuowa7KvcFGbB94YdM61jllN9ntw4vcedwvZH5nW3lpJJ6B55x2CZ0enHWV3llP kRsA== X-Gm-Message-State: APjAAAU51Zx2LLM14gzwgX9SVVk2X2mmK7ArxrQbH4S1EHvhX0dQkoAo NtfHNtsZ0EyZ0qQWI3gmt4nWPDGpW1fnFxUB76VBOw== X-Google-Smtp-Source: APXvYqzTpSPH+cBe6LlLDSpKphkGr0r0xfPseC0JOnxcRKwD1PfhAR8nsM73tuVcqTixadrdxhwNYlNrXApm8Ndkppo= X-Received: by 2002:a9d:6548:: with SMTP id q8mr15942333otl.132.1561112993753; Fri, 21 Jun 2019 03:29:53 -0700 (PDT) MIME-Version: 1.0 References: <20190617192700.2313445-1-andriin@fb.com> <30a2c470-5057-bd96-1889-e77fd5536960@iogearbox.net> In-Reply-To: From: Lorenz Bauer Date: Fri, 21 Jun 2019 11:29:42 +0100 Message-ID: Subject: Re: [PATCH v2 bpf-next 00/11] BTF-defined BPF map definitions To: Andrii Nakryiko Cc: Daniel Borkmann , Andrii Nakryiko , Alexei Starovoitov , Networking , bpf , Kernel Team , Jakub Kicinski , Joe Stringer Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, 21 Jun 2019 at 05:20, Andrii Nakryiko wrote: > > On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer wrote: > > > > On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko wrote: > > > > > > I would just drop the object-scope pinning. We avoided using it and I'm not > > > > aware if anyone else make use. It also has the ugly side-effect that this > > > > relies on AF_ALG which e.g. on some cloud provider shipped kernels is disabled. > > > > The pinning attribute should be part of the standard set of map attributes for > > > > libbpf though as it's generally useful for networking applications. > > > > > > Sounds good. I'll do some more surveying of use cases inside FB to see > > > if anyone needs object-scope pinning, just to be sure we are not > > > short-cutting anyone. > > > > I'm also curious what the use cases for declarative pinning are. From my > > limited POV it doesn't seem that useful? There are a couple of factors: > > Cilium is using it pretty extensively, so there are clearly use cases. > The most straigtforward use case is using a map created and shared by > another BPF program (to communicate, read stats, what have you). I think Cilium is in the quirky position that it has a persistent daemon, but shells out to tc for loading programs. They are probably also the most advanced (open-source) users of BPF out there. If I understood their comments correctly they want to move to using a library for loading their ELF. At that point whether something is possible in a declarative way is less important, because you have the much more powerful APIs at your disposal. Maybe Daniel or someone else from the Cilium team can chime in here? > > * Systemd mounts the default location only accessible to root, so I have to > > used my own bpffs mount. > > * Since I don't want to hard code that, I put it in a config file. > > * After loading the ELF we pin maps from the daemon managing the XDP. > > So mounting root would be specified per bpf_object, before maps are > created, so user-land driving application will have an opportunity to > tune everything. Declarative is only the per-map decision of whether > that map should be exposed to outer world (for sharing) or not. So `tc filter add bpf obj foo.elf pin-root /gobbledygook`? > Then check tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c > for more crazy syntax ;) > > typedef char * (* const (* const fn_ptr_arr2_t[5])())(char * (*)(int)); Not on a Friday ;P > > What if this did > > > > __type(value, struct my_value)[1000]; > > struct my_value __member(value)[1000]; // alternative > > > > instead, and skipped max_entries? > > I considered that, but decided for now to keep all those attributes > orthogonal for more flexibility and uniformity. This syntax might be > considered a nice "syntax sugar" and can be added in the future, if > necessary. Ack. > > At that point you have to understand that value is a pointer so all of > > our efforts > > are for naught. I suspect there is other weirdness like this, but I need to play > > with it a little bit more. > > Yes, C can let you do crazy stuff, if you wish, but I think that > shouldn't be a blocker for this proposal. I haven't seen any BPF > program doing that, usually you duplicate the type of inner value > inside your function anyway, so there is no point in taking > sizeof(map.value) from BPF program side. From outside, though, all the > types will make sense, as expected. Right, but in my mind that is a bit of a cop out. I like BTF map definitions, and I want them to be as unsurprising as possible, so that they are easy to use and adopt. If a type encodes all the information we need via the array dimension hack, couldn't we make the map variable itself a pointer, and drop the inner pointers? struct my_map_def { int type[BPF_MAP_TYPE_HASH]; int value; struct foo key; ... } struct my_map_def *my_map; -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com