From: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andriin@fb.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org, ast@fb.com
Cc: andrii.nakryiko@gmail.com, kernel-team@fb.com
Subject: Re: [PATCH v6 bpf-next 0/5] Add support for memory-mapping BPF array maps
Date: Mon, 18 Nov 2019 14:50:42 +0100 [thread overview]
Message-ID: <04403b43-3a08-e63e-729e-5f9e66ca0dc2@iogearbox.net> (raw)
In-Reply-To: <20191117172806.2195367-1-andriin@fb.com>
On 11/17/19 6:28 PM, Andrii Nakryiko wrote:
> This patch set adds ability to memory-map BPF array maps (single- and
> multi-element). The primary use case is memory-mapping BPF array maps, created
> to back global data variables, created by libbpf implicitly. This allows for
> much better usability, along with avoiding syscalls to read or update data
> completely.
>
> Due to memory-mapping requirements, BPF array map that is supposed to be
> memory-mapped, has to be created with special BPF_F_MMAPABLE attribute, which
> triggers slightly different memory allocation strategy internally. See
> patch 1 for details.
>
> Libbpf is extended to detect kernel support for this flag, and if supported,
> will specify it for all global data maps automatically.
>
> Patch #1 refactors bpf_map_inc() and converts bpf_map's refcnt to atomic64_t
> to make refcounting never fail. Patch #2 does similar refactoring for
> bpf_prog_add()/bpf_prog_inc().
>
> v5->v6:
> - add back uref counting (Daniel);
>
> v4->v5:
> - change bpf_prog's refcnt to atomic64_t (Daniel);
>
> v3->v4:
> - add mmap's open() callback to fix refcounting (Johannes);
> - switch to remap_vmalloc_pages() instead of custom fault handler (Johannes);
> - converted bpf_map's refcnt/usercnt into atomic64_t;
> - provide default bpf_map_default_vmops handling open/close properly;
>
> v2->v3:
> - change allocation strategy to avoid extra pointer dereference (Jakub);
>
> v1->v2:
> - fix map lookup code generation for BPF_F_MMAPABLE case;
> - prevent BPF_F_MMAPABLE flag for all but plain array map type;
> - centralize ref-counting in generic bpf_map_mmap();
> - don't use uref counting (Alexei);
> - use vfree() directly;
> - print flags with %x (Song);
> - extend tests to verify bpf_map_{lookup,update}_elem() logic as well.
>
> Andrii Nakryiko (5):
> bpf: switch bpf_map ref counter to atomic64_t so bpf_map_inc() never
> fails
> bpf: convert bpf_prog refcnt to atomic64_t
> bpf: add mmap() support for BPF_MAP_TYPE_ARRAY
> libbpf: make global data internal arrays mmap()-able, if possible
> selftests/bpf: add BPF_TYPE_MAP_ARRAY mmap() tests
>
Applied, thanks!
prev parent reply other threads:[~2019-11-18 13:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 17:28 [PATCH v6 bpf-next 0/5] Add support for memory-mapping BPF array maps Andrii Nakryiko
2019-11-17 17:28 ` [PATCH v6 bpf-next 1/5] bpf: switch bpf_map ref counter to atomic64_t so bpf_map_inc() never fails Andrii Nakryiko
2019-11-17 17:28 ` [PATCH v6 bpf-next 2/5] bpf: convert bpf_prog refcnt to atomic64_t Andrii Nakryiko
2019-11-17 17:28 ` [PATCH v6 bpf-next 3/5] bpf: add mmap() support for BPF_MAP_TYPE_ARRAY Andrii Nakryiko
2019-11-17 17:28 ` [PATCH v6 bpf-next 4/5] libbpf: make global data internal arrays mmap()-able, if possible Andrii Nakryiko
2019-11-17 17:28 ` [PATCH v6 bpf-next 5/5] selftests/bpf: add BPF_TYPE_MAP_ARRAY mmap() tests Andrii Nakryiko
2019-11-18 13:50 ` Daniel Borkmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04403b43-3a08-e63e-729e-5f9e66ca0dc2@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox