All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.