OvS and Socket Maps - Beyond ports as endpoints#

Aaron Conole (Red Hat)

• Why: A genuinely surprising datapath idea: treat application sockets as packet endpoints and skip the IP stack entirely. Measured ~1000ns of 7395ns per-packet protocol overhead in netns-to-netns forwarding — relevant to anyone watching eBPF/XDP-style bypass techniques reach general SDN tooling.
• What: An exploration with four prototype approaches (in-datapath table, userspace-centric, eBPF-based, plus a socket-map variant), with numbers: 7395 → 6190ns per packet (and ~23k more 65k-packets/s) using a sock(try) action to skip conntrack; the socket-map-style approach measured 8254ns — essentially identical to plain output, reported without spin. Difficulty is candidly labeled "very much a nightmare": tracking sockets across netns boundaries and rewriting recirc state. Preliminary patches are posted; the direction is undecided.
• How: OVS already knows the destination socket from tuple/conntrack state; sock() actions would enqueue directly to application sockets, skipping L3 routing and re-parsing inside the target netns, while trying to preserve OVS's flow-centric (megaflow) semantics.
• Where applicable: OVS kernel datapath with local (same-host) endpoints; experimental RFC stage (June 2025 ovs-dev thread). The eBPF variant is described as the most future-proof but hardest to integrate with OVS userspace.