From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: bpf <bpf@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
kernel-team <kernel-team@cloudflare.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Andrii Nakryiko <andriin@fb.com>,
Lorenz Bauer <lmb@cloudflare.com>,
Marek Majkowski <marek@cloudflare.com>,
Martin KaFai Lau <kafai@fb.com>, Yonghong Song <yhs@fb.com>
Subject: Re: BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks
Date: Tue, 18 Aug 2020 11:19:03 -0700 [thread overview]
Message-ID: <CAADnVQKE6y9h2fwX6OS837v-Uf+aBXnT_JXiN_bbo2gitZQ3tA@mail.gmail.com> (raw)
In-Reply-To: <87lficrm2v.fsf@cloudflare.com>
On Tue, Aug 18, 2020 at 8:49 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> : rcu_read_lock();
> : run_array = rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
> 0.01 : ffffffff817f8624: mov 0xd68(%r12),%rsi
> : if (run_array) {
> 0.00 : ffffffff817f862c: test %rsi,%rsi
> 0.00 : ffffffff817f862f: je ffffffff817f87a9 <__udp4_lib_lookup+0x2c9>
> : struct bpf_sk_lookup_kern ctx = {
> 1.05 : ffffffff817f8635: xor %eax,%eax
> 0.00 : ffffffff817f8637: mov $0x6,%ecx
> 0.01 : ffffffff817f863c: movl $0x110002,0x40(%rsp)
> 0.00 : ffffffff817f8644: lea 0x48(%rsp),%rdi
> 18.76 : ffffffff817f8649: rep stos %rax,%es:(%rdi)
> 1.12 : ffffffff817f864c: mov 0xc(%rsp),%eax
> 0.00 : ffffffff817f8650: mov %ebp,0x48(%rsp)
> 0.00 : ffffffff817f8654: mov %eax,0x44(%rsp)
> 0.00 : ffffffff817f8658: movzwl 0x10(%rsp),%eax
> 1.21 : ffffffff817f865d: mov %ax,0x60(%rsp)
> 0.00 : ffffffff817f8662: movzwl 0x20(%rsp),%eax
> 0.00 : ffffffff817f8667: mov %ax,0x62(%rsp)
> : .sport = sport,
> : .dport = dport,
> : };
Such heavy hit to zero init 56-byte structure is surprising.
There are two 4-byte holes in this struct. You can try to pack it and
make sure that 'rep stoq' is used instead of 'rep stos' (8 byte at a time vs 4).
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.
next prev parent reply other threads:[~2020-08-18 18:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 10:35 [PATCH bpf-next v5 00/15] Run a BPF program on socket lookup Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 01/15] bpf, netns: Handle multiple link attachments Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 02/15] bpf: Introduce SK_LOOKUP program type with a dedicated attach point Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 03/15] inet: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 04/15] inet: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 05/15] inet6: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 06/15] inet6: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 07/15] udp: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 08/15] udp: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 09/15] udp6: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 10/15] udp6: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 11/15] bpf: Sync linux/bpf.h to tools/ Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 12/15] libbpf: Add support for SK_LOOKUP program type Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 13/15] tools/bpftool: Add name mappings for SK_LOOKUP prog and attach type Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 14/15] selftests/bpf: Add verifier tests for bpf_sk_lookup context access Jakub Sitnicki
2020-07-17 10:35 ` [PATCH bpf-next v5 15/15] selftests/bpf: Tests for BPF_SK_LOOKUP attach point Jakub Sitnicki
2020-07-28 20:13 ` Andrii Nakryiko
2020-07-28 20:47 ` Daniel Borkmann
2020-07-29 8:55 ` Jakub Sitnicki
2020-07-31 0:04 ` Daniel Borkmann
2020-07-29 8:57 ` Jakub Sitnicki
2020-07-30 13:10 ` Jakub Sitnicki
2020-07-30 19:43 ` Andrii Nakryiko
2020-07-17 16:40 ` [PATCH bpf-next v5 00/15] Run a BPF program on socket lookup Lorenz Bauer
2020-07-18 3:25 ` Alexei Starovoitov
2020-08-18 15:49 ` BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks Jakub Sitnicki
2020-08-18 18:19 ` Alexei Starovoitov [this message]
2020-08-20 10:29 ` Jakub Sitnicki
2020-08-20 12:20 ` David Laight
2020-08-20 22:18 ` Alexei Starovoitov
2020-08-21 10:22 ` Jakub Sitnicki
2020-08-24 8:17 ` Paolo Abeni
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=CAADnVQKE6y9h2fwX6OS837v-Uf+aBXnT_JXiN_bbo2gitZQ3tA@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jakub@cloudflare.com \
--cc=kafai@fb.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=lmb@cloudflare.com \
--cc=marek@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.com \
/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).