From: Jakub Sitnicki <email@example.com> To: John Fastabend <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, Martin KaFai Lau <firstname.lastname@example.org> Subject: Re: [PATCH bpf-next 0/8] Extend SOCKMAP to store listening sockets Date: Mon, 25 Nov 2019 10:22:55 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <5dda1ed3e7f5d_62c72ad877f985c42f@john-XPS-13-9370.notmuch> On Sun, Nov 24, 2019 at 07:10 AM CET, John Fastabend wrote: > Jakub Sitnicki wrote: >> This patch set makes SOCKMAP more flexible by allowing it to hold TCP >> sockets that are either in established or listening state. With it SOCKMAP >> can act as a drop-in replacement for REUSEPORT_SOCKARRAY which reuseport >> BPF programs use. Granted, it is limited to only TCP sockets. >> >> The idea started out at LPC '19 as feedback from John Fastabend to our >> troubles with repurposing REUSEPORT_SOCKARRAY as a collection of listening >> sockets accessed by a BPF program ran on socket lookup . Without going >> into details, REUSEPORT_SOCKARRAY proved to be tightly coupled with >> reuseport logic. Talk from LPC (see slides  or video ) highlights >> what problems we ran into when trying to make REUSEPORT_SOCKARRAY work for >> our use-case. >> >> Patches have evolved quite a bit since the RFC series from a month ago >> . To recap the RFC feedback, John pointed out that BPF redirect helpers >> for SOCKMAP need sane semantics when used with listening sockets , and >> that SOCKMAP lookup from BPF would be useful . While Martin asked for >> UDP support . > > Curious if you've started looking into UDP support. I had hoped to do > it but haven't got there yet. No, not yet. I only made sure the newly added tests were easy to modify to cover UDP by not hard-coding the socket type. I expect to break ground with UDP work soon, though. Right after I push out another iteration of programmable socket lookup  patches adapted for SOCKMAP, which we've been testing internally. >> As it happens, patches needed more work to get SOCKMAP to actually behave >> correctly with listening sockets. It turns out flexibility has its >> price. Change log below outlines them all. >> > > But looks pretty clean to me, only major change here is to add an extra > hook to remove psock from the child socket. And that looks fine to me and > cleaner than any other solution I had in mind. > > Changes +/- looks good as well most the updates are in selftests to update > tests and add some new ones. +1 Thanks for taking a look at the patches so quickly. I appreciate it. -Jakub  https://firstname.lastname@example.org/
prev parent reply other threads:[~2019-11-25 9:23 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-23 11:07 Jakub Sitnicki 2019-11-23 11:07 ` [PATCH bpf-next 1/8] bpf, sockmap: Return socket cookie on lookup from syscall Jakub Sitnicki 2019-11-24 5:32 ` John Fastabend 2019-11-23 11:07 ` [PATCH bpf-next 2/8] bpf, sockmap: Let all kernel-land lookup values in SOCKMAP Jakub Sitnicki 2019-11-24 5:35 ` John Fastabend 2019-11-23 11:07 ` [PATCH bpf-next 3/8] bpf, sockmap: Allow inserting listening TCP sockets into SOCKMAP Jakub Sitnicki 2019-11-24 5:38 ` John Fastabend 2019-11-23 11:07 ` [PATCH bpf-next 4/8] bpf, sockmap: Don't let child socket inherit psock or its ops on copy Jakub Sitnicki 2019-11-24 5:56 ` John Fastabend 2019-11-25 22:38 ` Martin Lau 2019-11-26 15:54 ` Jakub Sitnicki 2019-11-26 17:16 ` Martin Lau 2019-11-26 18:36 ` Jakub Sitnicki [not found] ` <email@example.com> 2019-12-11 17:20 ` Martin Lau 2019-12-12 11:27 ` Jakub Sitnicki 2019-12-12 19:23 ` Martin Lau 2019-12-17 15:06 ` Jakub Sitnicki 2019-11-26 18:43 ` John Fastabend 2019-11-27 22:18 ` Jakub Sitnicki 2019-11-23 11:07 ` [PATCH bpf-next 5/8] bpf: Allow selecting reuseport socket from a SOCKMAP Jakub Sitnicki 2019-11-24 5:57 ` John Fastabend 2019-11-25 1:24 ` Alexei Starovoitov 2019-11-25 4:17 ` John Fastabend 2019-11-25 10:40 ` Jakub Sitnicki 2019-11-25 22:07 ` Martin Lau 2019-11-26 14:30 ` Jakub Sitnicki 2019-11-26 19:03 ` Martin Lau 2019-11-27 21:34 ` Jakub Sitnicki 2019-11-23 11:07 ` [PATCH bpf-next 6/8] libbpf: Recognize SK_REUSEPORT programs from section name Jakub Sitnicki 2019-11-24 5:57 ` John Fastabend 2019-11-23 11:07 ` [PATCH bpf-next 7/8] selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP Jakub Sitnicki 2019-11-24 6:00 ` John Fastabend 2019-11-25 22:30 ` Martin Lau 2019-11-26 14:32 ` Jakub Sitnicki 2019-12-12 10:30 ` Jakub Sitnicki 2019-11-23 11:07 ` [PATCH bpf-next 8/8] selftests/bpf: Tests for SOCKMAP holding listening sockets Jakub Sitnicki 2019-11-24 6:04 ` John Fastabend 2019-11-24 6:10 ` [PATCH bpf-next 0/8] Extend SOCKMAP to store " John Fastabend 2019-11-25 9:22 ` Jakub Sitnicki [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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH bpf-next 0/8] Extend SOCKMAP to store listening sockets' \ /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
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).