bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Jakub Sitnicki <jakub@cloudflare.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Lorenz Bauer <lmb@cloudflare.com>,
	kernel-team@cloudflare.com, netdev@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup
Date: Wed, 11 Mar 2020 15:40:43 -0700	[thread overview]
Message-ID: <5e6968eb5c09c_20552ab9153405b419@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <87y2s7xayn.fsf@cloudflare.com>

Jakub Sitnicki wrote:
> On Tue, Mar 10, 2020 at 06:47 PM CET, Lorenz Bauer wrote:
> > We want to use sockhash and sockmap to build the control plane for
> > our upcoming BPF socket dispatch work. We realised that it's
> > difficult to resize or otherwise rebuild these maps if needed,
> > because there is no way to get at their contents. This patch set
> > allows a privileged user to retrieve fds from these map types,
> > which removes this obstacle.
> 
> Since it takes just a few lines of code to get an FD for a sock:
> 
> 	fd = get_unused_fd_flags(O_CLOEXEC);
> 	if (unlikely(fd < 0))
> 		return fd;
>         fd_install(fd, get_file(sk->sk_socket->file));
> 
> ... I can't help but wonder where's the catch?
> 
> IOW, why wasn't this needed so far?
> How does Cilium avoid resizing & rebuilding sockmaps?

I build a map at init time and pin it for the lifetime of the daemon.
If we overrun the sockmap we can always fall back to the normal case
so there has never been a reason to resize.

I guess being able to change the map size at runtime would be a nice
to have but we don't do this with any other maps, e.g. connection
tracking, load balancing, etc. We expect good-sizing upfront. 

@Lorenz, Would it be possible to provide some more details where a
resize would be used? I guess if the map is nearly full you could
rebuild a bigger one and migrate? One thing I explored at one point
is to just create a new map and use multiple maps in the datapath
but that required extra lookups and for hashing might not be ideal.

> 
> Just asking out of curiosity.
> 
> [...]



  reply	other threads:[~2020-03-11 22:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 17:47 [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup Lorenz Bauer
2020-03-10 17:47 ` [PATCH 1/5] bpf: add map_copy_value hook Lorenz Bauer
2020-03-10 17:47 ` [PATCH 2/5] bpf: convert queue and stack map to map_copy_value Lorenz Bauer
2020-03-11 14:00   ` Jakub Sitnicki
2020-03-11 22:31     ` John Fastabend
2020-03-10 17:47 ` [PATCH 3/5] bpf: convert sock map and hash " Lorenz Bauer
2020-03-11 13:55   ` Jakub Sitnicki
2020-03-10 17:47 ` [PATCH 4/5] bpf: sockmap, sockhash: return file descriptors from privileged lookup Lorenz Bauer
2020-03-11 23:27   ` John Fastabend
2020-03-17 10:17     ` Lorenz Bauer
2020-03-17 15:18   ` Jakub Sitnicki
2020-03-17 18:16     ` John Fastabend
2020-03-10 17:47 ` [PATCH 5/5] bpf: sockmap, sockhash: test looking up fds Lorenz Bauer
2020-03-11 13:52   ` Jakub Sitnicki
2020-03-11 17:24     ` Lorenz Bauer
2020-03-11 13:44 ` [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup Jakub Sitnicki
2020-03-11 22:40   ` John Fastabend [this message]
2020-03-12  1:58 ` Alexei Starovoitov
2020-03-12  9:16   ` Lorenz Bauer
2020-03-12 17:58     ` Alexei Starovoitov
2020-03-12 19:32       ` John Fastabend
2020-03-13 11:03         ` Lorenz Bauer
2020-03-13 10:48       ` Lorenz Bauer
2020-03-14  2:58         ` Alexei Starovoitov
2020-03-17  9:55           ` Lorenz Bauer
2020-03-17 19:05             ` John Fastabend
2020-03-20 15:12               ` Lorenz Bauer
2020-04-07  3:08                 ` Alexei Starovoitov

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=5e6968eb5c09c_20552ab9153405b419@john-XPS-13-9370.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jakub@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=lmb@cloudflare.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;
as well as URLs for NNTP newsgroup(s).