mirror of
https://github.com/slackhq/nebula.git
synced 2026-11-15 14:06:52 +01:00
Wade Simmons
53c565eb29
Lanes were collapsing onto lane 0 and staying there. Nebula writes a peer's inbound packets to the tun queue matching the socket they arrived on, and tun_flow_update teaches the kernel to steer that flow's outbound packets to the same queue, preferring what it learned over the hash. So while a tunnel's lanes were still down -- which is every tunnel, for its first moments -- all traffic arrived on socket 0, pinning every flow to queue 0 on both hosts for as long as it stayed busy. With the lane following the routine, that meant lane 0 forever. Two changes break the loop: Choose the lane from the packet's own 5-tuple hash, so lane spread no longer depends on tun steering at all. The hash is symmetric, and the high-addressed side rotates its choice by the low side's port offset, so a flow's two directions land on partner lanes with exact reverse 4-tuples and each arrives through the conntrack entry the other's probe opened. Seed every lane as demanded at lane-set creation, so the first traffic tick probes them all at once rather than waiting for a flow to hash onto each. Lanes have to be up before the flows are, not after. A routine may now send on any lane, so it holds a SendBatch per lane, built lazily and all borrowing one shared arena -- the slab is the expensive part, and a batch per (routine, lane) would otherwise cost hundreds of megabytes. full() counts across the batches so the total outstanding stays bounded as before. That also means several routines can write to one socket, which was already true for base traffic under multiport: the linux batchWriter's sendmmsg scratch had no lock. Take a mutex there, once per flush.