From: Paolo Abeni <pabeni@redhat.com>
To: Craig Gallek <kraigatgoog@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [RFC PATCH] reuseport: compute the ehash only if needed
Date: Tue, 12 Dec 2017 19:25:44 +0100 [thread overview]
Message-ID: <1513103144.3294.15.camel@redhat.com> (raw)
In-Reply-To: <CAEfhGiwOrpkKJWXgdesFS=OUjOmr4BmUCRVFJy32G-N_g2+SGw@mail.gmail.com>
Hi,
On Tue, 2017-12-12 at 12:44 -0500, Craig Gallek wrote:
> On Tue, Dec 12, 2017 at 8:09 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> > When a reuseport socket group is using a BPF filter to distribute
> > the packets among the sockets, we don't need to compute any hash
> > value, but the current reuseport_select_sock() requires the
> > caller to compute such hash in advance.
> >
> > This patch reworks reuseport_select_sock() to compute the hash value
> > only if needed - missing or failing BPF filter. Since different
> > hash functions have different argument types - ipv4 addresses vs ipv6
> > ones - to avoid over-complicate the interface, reuseport_select_sock()
> > is now a macro.
>
> Purely subjective, but I think a slightly more complicated function
> signature for reuseport_select_sock (and reuseport_select_sock6?)
> would look a little better than this macro. It would avoid needing to
> expose the reuseport_info struct and would keep the rcu semantics
> entirely within the function call (the fast-path memory access
> semantics here are already non-trivial...)
Thanks for the feedback.
I was in doubt about the macro, too. The downside of using explicit
functions is the very long argument list and the need of 2 separate
functions for ipv4 and ipv6.
> > Additionally, the sk_reuseport test is move inside reuseport_select_sock,
> > to avoid some code duplication.
> >
> > Overall this gives small but measurable performance improvement
> > under UDP flood while using SO_REUSEPORT + BPF.
>
> Exciting, do you have some specific numbers here? I'd be interested
> in knowing what kinds of loads you end up seeing improvements for.
this are the numbers I collected so far:
(ipv4)
socks nr vanilla(kpps) patched(kpps)
1 1747 1843
2 3109 3140
3 4480 4534
4 5796 5864
5 7063 7139
6 8168 8235
(ipv6)
socks nr vanilla(kpps) patched(kpps)
1 1433 1544
2 2537 2731
3 3622 3794
4 4689 4979
5 5738 6011
6 6671 6920
Cheers,
Paolo
next prev parent reply other threads:[~2017-12-12 18:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 17:44 [RFC PATCH] reuseport: compute the ehash only if needed Craig Gallek
2017-12-12 18:25 ` Paolo Abeni [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-12-12 13:09 Paolo Abeni
2017-12-13 20:08 ` David Miller
2017-12-14 8:29 ` Paolo Abeni
2017-12-14 13:41 ` David Miller
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=1513103144.3294.15.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kraigatgoog@gmail.com \
--cc=netdev@vger.kernel.org \
/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.