feat: Cut CNI ADD over to eBPF uSID registration

[privateip]

Summary

Fourth PR in the eBPF uSID datapath stack (on top of #283, the datapath control-plane packages).

Removes the legacy per-route netlink SRv6 ingress mechanism (srv6.RouteIngressAdd/Del, all of srv6.go) entirely and replaces it with registration against the eBPF uSID datapath's pinned maps. The eBPF/TC-BPF datapath is now the only ingress/decap path for both veth and tap attachments — there's no dual-path coexistence to maintain.

ComputeSID is rewritten onto the shared uFMT 48+16 bit layout (internal/plumbing/ebpf/uformat, #281) instead of its previous ad hoc NodeID/VRFID/Function suffix, so the BGP control plane and the eBPF dataplane can never drift on bit positions.

The CNI ADD path no longer derives the VRFID straight from the VPCAttachment identifier; it now allocates a 12-bit uFMT Argument per node from live BGPVRFInstance CRD state (allocateArgument), with a collision check (checkArgumentCollision) covering the allocate-then-create race between two concurrent ADDs. registerEBPFDatapath/unregisterEBPFDatapath write and roll back the three eBPF map entries (locator_table, function_table, vrf_table) for each attachment.

Note

This branch is built directly on #283, not on #284 (the independent BGPAdvertisement prefix-merge fix) — those two touch nearby code in bgp.go but have no real dependency on each other. Merging #284 first and rebasing this stack is the cleanest order; otherwise expect a normal merge conflict in bgp.go at merge time.

Gateway ARP/NDP neighbor priming (installGatewayNeighbor) is a separate concern and lands in its own follow-up PR stacked on this one.

Test plan

• go build ./...
• go vet ./...
• go test ./internal/cni/... ./internal/plumbing/srv6/... (one pre-existing unrelated failure: TestUpdateForwardRuleInvalidAction needs an iptables binary not present in this sandbox)
• task lint (0 issues)

Part of the eBPF uSID datapath cutover stack (base: #283).

[ecv]

Same disclosure as elsewhere in the stack — ecv reviewed this through an AI shell, apologies. Questions, not verdicts.

Two pieces of care worth naming. Checking nodeID against its real range before the uint16 narrowing, with a comment showing that 65537 wraps to a plausible 1, catches a bug that would have registered a locator this node was never assigned. And unregisterEBPFDatapath refusing to delete a slot whose VRF table id no longer matches — because a retry may have let another attachment overwrite it — reasons correctly about a subtle race.

1. allocateArgument short-circuits on an existing BGPVRFInstance and returns its stored VRFID without checking it. The old code parsed that field as a full 16-bit value, so it ranges 0 to 65535; the new Argument range runs 1 to 4095. An existing instance holding anything outside that range flows straight into VRF.Register, which rejects it, and the ADD fails. It fails the same way on every retry, and feat: eBPF vrf_table GC sweep and control-daemon startup #287's sweep skips out-of-range VRFIDs rather than renumbering them, so nothing repairs it. Do any clusters hold BGPVRFInstance objects written by the old code? If containerlab or a dev cluster does, those attachments stop starting after this lands.

2. allocateArgument lists every BGPVRFInstance in the namespace, then checkArgumentCollision lists them all again. One BGPRouter per node and one namespace means each list returns every attachment in the cluster, so a pod start costs two full reads against a client that does not cache. Has this run against a namespace with a few thousand attachments?

3. The collision error is a plain fmt.Errorf, so isTransientError says no and retryK8sOps returns at once. That rolls the whole ADD back and leaves the retry to kubelet, when re-running the closure would list again and take the next free Argument. Should the collision count as transient?

4. The kernel VRF table id still derives from (vpc, vpcAttachment), so it matches on every node. The Argument is now the first free slot per node, so it differs. One attachment now carries two numbers that disagree across nodes. Is that difference written down anywhere an operator would look?

5. This removes the code that installs the seg6local ingress routes, but nothing removes routes already in the kernel. That matters more than dead config: usid.c returns TC_ACT_OK on a locator miss, which hands the packet to the normal routing stack, where a leftover seg6local route still decapsulates it. A missing or wrong map registration would then keep working on every node that ran the old code and fail only on fresh ones. Is there a cleanup step for those routes, or does the upgrade path assume a rebuild?

6. The comment explains that locator and function registration moved here because the control daemon never watches BGPRouter, and calls that a departure from the design plan to revisit. Neither table has any GC either (asked on feat: eBPF vrf_table GC sweep and control-daemon startup #287). What closes both halves — a CRD watch in the daemon, or reconciliation from here?

[ecv]

conflicts