From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <lmb@isovalent.com>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <bpf@vger.kernel.org>,
<daniel@iogearbox.net>, <davem@davemloft.net>,
<dsahern@kernel.org>, <edumazet@google.com>, <haoluo@google.com>,
<hemanthmalla@gmail.com>, <joe@wand.net.nz>,
<john.fastabend@gmail.com>, <jolsa@kernel.org>,
<kpsingh@kernel.org>, <kuba@kernel.org>, <kuniyu@amazon.com>,
<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<martin.lau@linux.dev>, <mykolal@fb.com>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>, <sdf@google.com>,
<shuah@kernel.org>, <song@kernel.org>,
<willemdebruijn.kernel@gmail.com>, <yhs@fb.com>
Subject: Re: [PATCH bpf-next v2 3/6] net: remove duplicate reuseport_lookup functions
Date: Wed, 21 Jun 2023 08:00:58 -0700 [thread overview]
Message-ID: <20230621150058.59250-1-kuniyu@amazon.com> (raw)
In-Reply-To: <CAN+4W8gYuW5P3t5881YdMq1pYnG9DsQJFiJWPoLFsKVsZiLLQQ@mail.gmail.com>
From: Lorenz Bauer <lmb@isovalent.com>
Date: Wed, 21 Jun 2023 09:01:15 +0100
> On Tue, Jun 20, 2023 at 7:31 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > Good point. This is based on an assumption that all SO_REUSEPORT
> > sockets have the same score, which is wrong for two corner cases
> > if reuseport_has_conns() == true :
> >
> > 1) SO_INCOMING_CPU is set
> > -> selected sk might have +1 score
> >
> > 2) BPF prog returns ESTABLISHED and/or SO_INCOMING_CPU sk
> > -> selected sk will have more than 8
> >
> > Using the old score could trigger more lookups depending on the
> > order that sockets are created.
>
> So the result will still be correct, but it's less performant? Happy
> to fix a perf regression, but if the result is incorrect this might
> need a separate fix?
Right, the result is always correct.
If BPF prog selects a different socket per lookup, there is no
consistency, but it _is_ corret.
> I did some more digging. I think this was introduced by commit
> efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") which
> unfortunately ran into a merge conflict. That resulted in Dave Miller
> moving the bug around in commit a57066b1a019 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"). Can you
> take a look and let me know if you think that is correct?
Yes, I should have updated the score too in efc6b6f6c311 to save
unneeded lookups. The conflict itself was resolved properly.
next prev parent reply other threads:[~2023-06-21 15:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 10:14 [PATCH bpf-next v2 0/6] Add SO_REUSEPORT support for TC bpf_sk_assign Lorenz Bauer
2023-06-13 10:14 ` [PATCH bpf-next v2 1/6] net: export inet_lookup_reuseport and inet6_lookup_reuseport Lorenz Bauer
2023-06-13 10:14 ` [PATCH bpf-next v2 2/6] net: document inet[6]_lookup_reuseport sk_state requirements Lorenz Bauer
2023-06-13 10:14 ` [PATCH bpf-next v2 3/6] net: remove duplicate reuseport_lookup functions Lorenz Bauer
2023-06-13 15:32 ` Simon Horman
2023-06-14 15:42 ` Lorenz Bauer
2023-06-15 7:21 ` Simon Horman
2023-06-13 17:26 ` kernel test robot
2023-06-13 18:56 ` Kuniyuki Iwashima
2023-06-14 15:25 ` Lorenz Bauer
2023-06-14 16:52 ` Kuniyuki Iwashima
2023-06-20 14:26 ` Lorenz Bauer
2023-06-20 18:31 ` Kuniyuki Iwashima
2023-06-21 8:01 ` Lorenz Bauer
2023-06-21 13:49 ` Lorenz Bauer
2023-06-21 15:00 ` Kuniyuki Iwashima [this message]
2023-06-13 10:14 ` [PATCH bpf-next v2 4/6] net: remove duplicate sk_lookup helpers Lorenz Bauer
2023-06-13 19:03 ` Kuniyuki Iwashima
2023-06-13 19:41 ` kernel test robot
2023-06-13 10:15 ` [PATCH bpf-next v2 5/6] bpf, net: Support SO_REUSEPORT sockets with bpf_sk_assign Lorenz Bauer
2023-06-13 17:26 ` kernel test robot
2023-06-13 10:15 ` [PATCH bpf-next v2 6/6] selftests/bpf: Test that SO_REUSEPORT can be used with sk_assign helper Lorenz Bauer
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=20230621150058.59250-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=hemanthmalla@gmail.com \
--cc=joe@wand.net.nz \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lmb@isovalent.com \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--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.