All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Lau <kafai@fb.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"kernel-team@cloudflare.com" <kernel-team@cloudflare.com>
Subject: Re: [RFC bpf-next 0/5] Extend SOCKMAP to store listening sockets
Date: Mon, 28 Oct 2019 05:52:56 +0000	[thread overview]
Message-ID: <20191028055247.bh5bctgxfvmr3zjh@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20191022113730.29303-1-jakub@cloudflare.com>

On Tue, Oct 22, 2019 at 01:37:25PM +0200, Jakub Sitnicki wrote:
> This patch set is a follow up on a suggestion from LPC '19 discussions to
> make SOCKMAP (or a new map type derived from it) a generic type for storing
> established as well as listening sockets.
> 
> We found ourselves in need of a map type that keeps references to listening
> sockets when working on making the socket lookup programmable, aka BPF
> inet_lookup [1].  Initially we repurposed REUSEPORT_SOCKARRAY but found it
> problematic to extend due to being tightly coupled with reuseport
> logic (see slides [2]).
> So we've turned our attention to SOCKMAP instead.
> 
> As it turns out the changes needed to make SOCKMAP suitable for storing
> listening sockets are self-contained and have use outside of programming
> the socket lookup. Hence this patch set.
> 
> With these patches SOCKMAP can be used in SK_REUSEPORT BPF programs as a
> drop-in replacement for REUSEPORT_SOCKARRAY for TCP. This can hopefully
> lead to code consolidation between the two map types in the future.
What is the plan for UDP support in sockmap?

> 
> Having said that, the main intention here is to lay groundwork for using
> SOCKMAP in the next iteration of programmable socket lookup patches.
What may be the minimal to get only lookup work for UDP sockmap?
.close() and .unhash()?

> 
> I'm looking for feedback if there's anything fundamentally wrong with
> extending SOCKMAP map type like this that I might have missed.
> 
> Thanks,
> Jakub
> 
> [1] https://lore.kernel.org/bpf/20190828072250.29828-1-jakub@cloudflare.com/
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__linuxplumbersconf.org_event_4_contributions_487_attachments_238_417_Programmable-5Fsocket-5Flookup-5FLPC-5F19.pdf&d=DwIDAg&c=5VD0RTtNlTh3ycd41b3MUw&r=VQnoQ7LvghIj0gVEaiQSUw&m=Y-Ap1QuRBsqsu8gATb1wH3rPT89No2mam2qINt1BGDI&s=_sfXVfJhB2eR7znE7-WBk660dQXIBxuDLRi7jvXVpsg&e= 
> 
> 
> Jakub Sitnicki (5):
>   bpf, sockmap: Let BPF helpers use lookup operation on SOCKMAP
>   bpf, sockmap: Allow inserting listening TCP sockets into SOCKMAP
>   bpf, sockmap: Don't let child socket inherit psock or its ops on copy
>   bpf: Allow selecting reuseport socket from a SOCKMAP
>   selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP
> 
>  kernel/bpf/verifier.c                         |   6 +-
>  net/core/sock_map.c                           |  11 +-
>  net/ipv4/tcp_bpf.c                            |  30 ++++
>  tools/testing/selftests/bpf/Makefile          |   7 +-
>  .../selftests/bpf/test_select_reuseport.c     | 141 ++++++++++++++----
>  .../selftests/bpf/test_select_reuseport.sh    |  14 ++
>  6 files changed, 173 insertions(+), 36 deletions(-)
>  create mode 100755 tools/testing/selftests/bpf/test_select_reuseport.sh
> 
> -- 
> 2.20.1
> 

  parent reply	other threads:[~2019-10-28  5:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 11:37 [RFC bpf-next 0/5] Extend SOCKMAP to store listening sockets Jakub Sitnicki
2019-10-22 11:37 ` [RFC bpf-next 1/5] bpf, sockmap: Let BPF helpers use lookup operation on SOCKMAP Jakub Sitnicki
2019-10-24 16:59   ` John Fastabend
2019-10-22 11:37 ` [RFC bpf-next 2/5] bpf, sockmap: Allow inserting listening TCP sockets into SOCKMAP Jakub Sitnicki
2019-10-24 17:06   ` John Fastabend
2019-10-25  9:41     ` Jakub Sitnicki
2019-10-22 11:37 ` [RFC bpf-next 3/5] bpf, sockmap: Don't let child socket inherit psock or its ops on copy Jakub Sitnicki
2019-10-22 11:37 ` [RFC bpf-next 4/5] bpf: Allow selecting reuseport socket from a SOCKMAP Jakub Sitnicki
2019-10-22 11:37 ` [RFC bpf-next 5/5] selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP Jakub Sitnicki
2019-10-24 16:12 ` [RFC bpf-next 0/5] Extend SOCKMAP to store listening sockets Alexei Starovoitov
2019-10-24 16:56 ` John Fastabend
2019-10-25  9:26   ` Jakub Sitnicki
2019-10-25 14:18     ` John Fastabend
2019-10-28  5:52 ` Martin Lau [this message]
2019-10-28 12:35   ` Jakub Sitnicki
2019-10-28 19:04     ` John Fastabend
2019-10-29  8:56       ` Jakub Sitnicki
2019-10-28 20:42     ` Martin Lau
2019-10-28 21:05       ` John Fastabend
2019-10-28 21:38         ` Martin Lau
2019-10-29  8:52           ` Jakub Sitnicki

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=20191028055247.bh5bctgxfvmr3zjh@kafai-mbp.dhcp.thefacebook.com \
    --to=kafai@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=jakub@cloudflare.com \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-team@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.