[w180112]

Summary

• Replace rte_hash_reset / rte_ring_reset with per-entry rte_hash_del_key for clearing the NAT and IPv6 firewall tables on reconfig. rte_hash_reset / rte_ring_reset are not thread-safe against a concurrent GC reader; the previous code only got away with it because the caller happened to mark entries FREE, drain the defer queue, and stop feeding new packets first, with enough timing slack in between. The delete path walks the same per-entry route as GC, so it is safe to run concurrently with GC by construction, not by timing. The gate is still closed first, followed by one RCU grace period before the slots are freed — this rte_rcu_qsbr_synchronize call is defensive. On the measured call path, the data plane has already stopped feeding this subscriber for >=1.5 ms (processing one packet takes about 1.6 us) before the table clear even starts, so there is no reachable race on today's call paths. Please do not read this as "fixes a race that happens today."
• Split the one-time table initialization into *_init_entries and *_enqueue_all_entries_to_ring, and remove the unused FILLING state.
• Add unit tests for the new delete-based clearing functions; no existing test cases were modified.

What the measurements actually show

• The reachable defect on current master: clearing used rte_hash_reset / rte_ring_reset, which makes the ring's "used" counter jump to MAX and then refill over ~3-5 ms. During that refill window, /metrics can report up to ~260k NAT entries / tens of thousands of IPv6 firewall entries for the affected subscriber even though no such entries exist. Dense on-node sampling: master showed this false reading in 60/60 reconfig rounds across three independent runs; this branch showed it in 0/60 rounds.
• There is no evidence of in-flight-packet-vs-clear or GC-vs-clear races on any call path reachable today (dial-triggered reconfig, subscriber-count decrease, etc.) — this was confirmed both by code review of every caller of the table-clear routines and by targeted timing instrumentation on a master build. The grace period in this PR exists to keep that guarantee if a future caller clears the table closer to the gate close, not because such a caller exists now.

e2e additions

• New Step 155b (phase36, RSS) and Step 190b (phase41, software distributor): drop and re-add a subscriber under continuous new-flow load while sampling NAT / IPv6 firewall usage on the node at ~1 ms resolution, and assert that no sample ever exceeds the pre-drop high-water mark. Verdicts are lib predicates (e2e_reconfig_race_verdict, e2e_nat_entries_unique, e2e_reconfig_race_node_verdict) with fixtures, and are exercised by dedicated drills (reconfig_race_trigger_skipped, reconfig_race_sampler_sparse) to confirm the checks actually fail when they should.
• A new guard (e2e_test/phases/bras_pool_lib.sh) that fails loudly, with the offending log line quoted, whenever the lab BRAS (dpdk-bras) reports "IP pool exhausted". Once the pool is exhausted, every subsequent PPPoE dial in the run is rejected for a reason that has nothing to do with the node under test, which previously made unrelated failures look like node bugs.

Dependency on an out-of-repo fix (bench only, not part of this PR)

Full e2e runs depend on a fix to the lab BRAS (dpdk-bras) that makes its IP address and IPv6 PD allocation recycle properly instead of binding addresses to monotonically increasing session IDs. That fix lives in the separate dpdk-bras repo and has already been built and deployed to the bench BRAS (10.215); it is not part of this PR. Without it, a full e2e run exhausts the address pool during the VALIDATE phase.

Test results

• make test: 2458 tests passed.
• make all: builds clean.
• Full e2e: 208/208 passed. Local validation: 248/248. VALIDATE: 29/29 caught, 0 polluted.

🤖 Generated with Claude Code