Hi, On Tue, 2017-12-12 at 12:44 -0500, Craig Gallek wrote: > On Tue, Dec 12, 2017 at 8:09 AM, Paolo Abeni <pab...@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
