Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3821947ybi; Fri, 5 Jul 2019 14:54:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxO2rBN6NxR9yRubB+MNsbDEtqWAeFjsIwJC4r10+LKY7tqw0+RHLwlo5CW9ScpRqH0G4dS X-Received: by 2002:a17:902:8509:: with SMTP id bj9mr8068089plb.79.1562363646403; Fri, 05 Jul 2019 14:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562363646; cv=none; d=google.com; s=arc-20160816; b=JWb6DthxSuOkwQBV9gFQ8E3zHFXx2vPSIiBFOYgDQqpxl0VoXal3D5vzOn/zmMZyIf NWtDeagxQIxY8x791UkG22+7L/OQCq0TZ5l1rMxtG7htXSGL+tIGp3RPMDGROAgL9whw tOjH0chJbuA+eXaoPhZuTeZlTJaUPdnJUmpYD4wB9CTm7CwBNlzPFkHHQmgBf0U2j6AO n+64EsT0OzeDC6TM8CTNlKQfcFyClLMT/4zRr/vtNjlOi7OTrkAEHgxEA1O/r0Ec3/78 eNyfVfgkMWfiARtIjMA2zp2xtmy/tUHzVuOULbXRymppUr1l9J5o34P9TdhFuh3N1N41 g/zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=40II/55syTY8F1OZAtCTvjAJRpROq7HTKg57eMKsZp8=; b=G1YfFFs3voFOrDkaQ0nFsO5gyvNkMaPAyOcL/XHXYPAHET5xcl7KH1FJ4rkhs3GIM6 CRCpM9+PEq9GpoQ2uoQMb60OJPpZAm6IRch8CXBZUj8NEOy9Q8u79YBp5PEhADSO+u9l Rmnu2u+QRfeYFZUygsjX12wPxNKjy6Db5QQ2AfcY1QdbnU7+f5jVW0Iwnbcw/KhEVBjJ 8r+n+00C5l2ScWNcEBBfjVI2vBZtFlDNa9OXqqEhC0zHe+TBrAHhu05pj0DkWdvXn6xp h1cp80JsmGtUMOINJzS0j7PD62R8TNdtSvfJyuVSLktr0p1qHukjMSZqHAKSrjlqK+MB kg4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id az12si6477437plb.5.2019.07.05.14.53.51; Fri, 05 Jul 2019 14:54:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728276AbfGEVow (ORCPT + 99 others); Fri, 5 Jul 2019 17:44:52 -0400 Received: from www62.your-server.de ([213.133.104.62]:49732 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726559AbfGEVow (ORCPT ); Fri, 5 Jul 2019 17:44:52 -0400 Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1hjW0b-0002eV-FV; Fri, 05 Jul 2019 23:44:45 +0200 Received: from [178.193.45.231] (helo=linux.home) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hjW0b-0000iX-6b; Fri, 05 Jul 2019 23:44:45 +0200 Subject: Re: [PATCH bpf-next 1/2] bpf, libbpf: add a new API bpf_object__reuse_maps() To: Anton Protopopov , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, andriin@fb.com References: From: Daniel Borkmann Message-ID: <734dd45a-95b0-a7fd-9e1d-0535ef4d3e12@iogearbox.net> Date: Fri, 5 Jul 2019 23:44:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.100.3/25501/Fri Jul 5 10:01:52 2019) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/05/2019 10:44 PM, Anton Protopopov wrote: > Add a new API bpf_object__reuse_maps() which can be used to replace all maps in > an object by maps pinned to a directory provided in the path argument. Namely, > each map M in the object will be replaced by a map pinned to path/M.name. > > Signed-off-by: Anton Protopopov > --- > tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++++++ > tools/lib/bpf/libbpf.h | 2 ++ > tools/lib/bpf/libbpf.map | 1 + > 3 files changed, 37 insertions(+) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 4907997289e9..84c9e8f7bfd3 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -3144,6 +3144,40 @@ int bpf_object__unpin_maps(struct bpf_object *obj, const char *path) > return 0; > } > > +int bpf_object__reuse_maps(struct bpf_object *obj, const char *path) > +{ > + struct bpf_map *map; > + > + if (!obj) > + return -ENOENT; > + > + if (!path) > + return -EINVAL; > + > + bpf_object__for_each_map(map, obj) { > + int len, err; > + int pinned_map_fd; > + char buf[PATH_MAX]; We'd need to skip the case of bpf_map__is_internal(map) since they are always recreated for the given object. > + len = snprintf(buf, PATH_MAX, "%s/%s", path, bpf_map__name(map)); > + if (len < 0) { > + return -EINVAL; > + } else if (len >= PATH_MAX) { > + return -ENAMETOOLONG; > + } > + > + pinned_map_fd = bpf_obj_get(buf); > + if (pinned_map_fd < 0) > + return pinned_map_fd; Should we rather have a new map definition attribute that tells to reuse the map if it's pinned in bpf fs, and if not, we create it and later on pin it? This is what iproute2 is doing and which we're making use of heavily. In bpf_object__reuse_maps() bailing out if bpf_obj_get() fails is perhaps too limiting for a generic API as new version of an object file may contain new maps which are not yet present in bpf fs at that point. > + err = bpf_map__reuse_fd(map, pinned_map_fd); > + if (err) > + return err; > + } > + > + return 0; > +} > + > int bpf_object__pin_programs(struct bpf_object *obj, const char *path) > { > struct bpf_program *prog; > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > index d639f47e3110..7fe465a1be76 100644 > --- a/tools/lib/bpf/libbpf.h > +++ b/tools/lib/bpf/libbpf.h > @@ -82,6 +82,8 @@ int bpf_object__variable_offset(const struct bpf_object *obj, const char *name, > LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char *path); > LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj, > const char *path); > +LIBBPF_API int bpf_object__reuse_maps(struct bpf_object *obj, > + const char *path); > LIBBPF_API int bpf_object__pin_programs(struct bpf_object *obj, > const char *path); > LIBBPF_API int bpf_object__unpin_programs(struct bpf_object *obj, > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map > index 2c6d835620d2..66a30be6696c 100644 > --- a/tools/lib/bpf/libbpf.map > +++ b/tools/lib/bpf/libbpf.map > @@ -172,5 +172,6 @@ LIBBPF_0.0.4 { > btf_dump__new; > btf__parse_elf; > bpf_object__load_xattr; > + bpf_object__reuse_maps; > libbpf_num_possible_cpus; > } LIBBPF_0.0.3; >