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...)
> 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. > Signed-off-by: Paolo Abeni <pab...@redhat.com>
