Page MenuHomeFreeBSD

netinet: add SO_REUSEPORT_LB_CPU for receive-CPU socket affinity
Needs ReviewPublic

Authored by nick_spun.io on Mon, Sep 7, 10:43 PM.

Details

Reviewers
adrian
markj
glebius
gallatin
Group Reviewers
network
transport
Summary

A SO_REUSEPORT_LB group distributes incoming connections among its
members with a hash of the connection four-tuple. That hash is
unrelated to the receive queue the NIC steered the flow to, so a worker
pinned to the CPU that processes a given receive queue cannot be handed
the flows that land on its own CPU, and the locality that receive-side
scaling sets up is lost at the socket layer.

Add a SO_REUSEPORT_LB_CPU socket option that tags a member socket with a
receive-CPU affinity. When a packet is processed on that CPU,
in_pcblookup_lbgroup() delivers it to the matching member in preference
to the hash. Members without an affinity, and packets whose processing
CPU matches no affinitized member, keep the hashed distribution.

The group counts affinitized members, so the lookup scan is skipped for
groups that use none and the common path is unchanged. The match uses
curcpu at lookup time, the CPU the stack actually processes the flow on,
so it holds under both direct and deferred netisr dispatch and without
options RSS compiled in.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 76657
Build 73540: arc lint + arc unit

Event Timeline

glebius added reviewers: network, transport.

Pardon naive quick question, before reading deeper into the proposal: any downsides with proposed behavior? Can it be on by default for SO_REUSEPORT_LB?

FWIW when we did LB we were really worried about breaking software, and in hindsight we maybe should have just aligned REUSEPORT across a major FreeBSD version with Linux to minimize third party software adaptation. Think hard before adding yet another non-portable sockopt; the LB_CPU_CURRENT behavior sounds desirable unless there is some corner you see. So I agree with Gleb.