All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	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: Mon, 24 Aug 2020 10:17:03 +0200	[thread overview]
Message-ID: <8ccf0b77c854a20f65026fdc68dcd64b93d07fc5.camel@redhat.com> (raw)
In-Reply-To: <CAADnVQKE6y9h2fwX6OS837v-Uf+aBXnT_JXiN_bbo2gitZQ3tA@mail.gmail.com>

On Tue, 2020-08-18 at 11:19 -0700, Alexei Starovoitov wrote:
> 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).

I think here rep stos is copying 8 bytes at a time (%rax operand, %ecx
initalized with '6').

I think that you can avoid the costly instruction explicitly
initializing each field individually:

	struct bpf_sk_lookup_kern ctx;

	ctx.family = AF_INET;
	ctx.protocol = protocol;
	// ...

note, you likely want to explicitly zero the v6 addresses, too.

Cheers,

Paolo


      parent reply	other threads:[~2020-08-24  8:17 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
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 [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 \
    --in-reply-to=8ccf0b77c854a20f65026fdc68dcd64b93d07fc5.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=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 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.