Re: BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks

On Fri, Aug 21, 2020 at 12:18 AM CEST, Alexei Starovoitov wrote:

On Thu, Aug 20, 2020 at 3:29 AM Jakub Sitnicki [off-list ref] wrote:

quoted

On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:

[...]

quoted

quoted

Long term we should probably stop doing *_kern style of ctx passing
into bpf progs.
We have BTF, CO-RE and freplace now. This old style of memset *_kern and manual
ctx conversion has performance implications and annoying copy-paste of ctx
conversion routines.
For this particular case instead of introducing udp4_lookup_run_bpf()
and copying registers into stack we could have used freplace of
udp4_lib_lookup2.
More verifier work needed, of course.
My main point that existing approach "lets prep args for bpf prog to
run" that is used
pretty much in every bpf hook is no longer necessary.

Andrii has also suggested leveraging BTF [0], but to expose the *_kern
struct directly to BPF prog instead of emitting ctx access instructions.

What I'm curious about is if we get rid of prepping args and ctx
conversion, then how do we limit what memory BPF prog can access?

Say, I'm passing a struct sock * to my BPF prog. If it's not a tracing
prog, then I don't want it to have access to everything that is
reachable from struct sock *. This is where this approach currently
breaks down for me.

Why do you want to limit it?
Time after time we keep extending structs in uapi/bpf.h because new
use cases are coming up. Just let the prog access everything.

I guess I wasn't thinking big enough :-)