The eBPF iterator interface is now per-CPU aware, and correctly
extracts a slice of data for each per-CPU map (or a slice of 1
when using a non-CPU divided map).
Replaces the eBPF interface "bpf_map_get_next_key" followed by
"bpf_map_lookup_elem" cycle for iterating maps with a call to
the kernel-provided eBPF iterator service.
Currently only implemented for throughput and RTT tracking.
Further commits will tighten the scope and eventually remove
the legacy setup completely.
For 10k hosts, this reduces the number of system calls from
20,002 to 4. The remaining items are a futex lock (required
for safety), and an iterator call.
New tool: lqos_map_perf is included in the distribution. It
runs the two map iterators that pound the lqosd/eBPF system
with map iterations, counts the number of entries returned
and reports on overall performance (in µs).
This is intended to help with diagnosing map reading
performance issues and act as a bench-test to see if
using eBPF iterators actually helps.
Adding "type" to `network.json` is awesome, but it broke a bit of
Rust. This patch adds support for the `type` field, and fixes
a rare "none" issue that mostly seems to affect my UISP setup.
Requested by D. Denson.
Now that the UISP network tree is built as a spanning tree, with 10
cost per hop we can reliably flip the tree from A->B->C to C->B->A
depending upon root positioning.
This addition allows you to specify additional routes (that MUST
exist!) e.g. A->C and specify a cost to use instead of the default
10. This allows for topologies in which A-B-C is actually faster
than a direct A-C route (for example, becuase of short 60ghz
hops).
Rather than obeying the "parent" field, which leads to wrong-way up
graphs when building from a non-root site - instead build a complete
cost-based spanning tree from the specified root node. Then use
the generated tree - falling back on parent if nothing is found -
to populate the tree in order.
Tested on Herbert's network, correctly generates topology from several
different locations.
Still to come: adding a mechanism for providing parenting overloads
to allow for cases where a long path is actually optimal, but we
have no way of knowing that.
