From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [RFC PATCH] reuseport: compute the ehash only if needed Date: Tue, 12 Dec 2017 19:25:44 +0100 Message-ID: <1513103144.3294.15.camel@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: netdev , "David S. Miller" , Eric Dumazet To: Craig Gallek Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53070 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752141AbdLLSZq (ORCPT ); Tue, 12 Dec 2017 13:25:46 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Hi, On Tue, 2017-12-12 at 12:44 -0500, Craig Gallek wrote: > On Tue, Dec 12, 2017 at 8:09 AM, Paolo Abeni 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