Rayhaan JaufeerallyandClaude Fable 5.1
48da8cc7d2
The routing table's shards started empty and grew as routes came in, each growth moving every row of the shard into a table twice the size. In a profile of the daemon taking in a full table, the growth showed as up to a seventh of the session's time, and the daemon's resident memory had the old and the new table of each shard side by side for a moment. This change adds `RibTable::expect_prefixes`, which reserves room for that many prefixes spread over the shards, and has the server call it at startup with the largest `expected_routes` among the configured peers: the prefixes of several full tables are mostly the same ones. Without `expected_routes` nothing changes. The `full_table` benchmark does the same unless `BENCH_PRESIZE=0`. Measured, the saving in time is within the run-to-run noise: in the Linux VM one peer's table is in the routing table in 0.81 s instead of 0.89 s, and the kernel is in step at about the same time as before; three pairs of runs of the benchmark on a Mac average 0.33 s against 0.35 s. The profile's attribution to the growth was mostly sampling skid. The memory saving is real: 442 MiB resident with one peer's table in instead of 483 MiB, and 626 MiB instead of 632 MiB with four. Also: the profiling script printed nothing for the kernel's change counts because it asked `/metrics` for them; the endpoint is `/metricz`. With that fixed, a four-peer load shows 1.25 million installs for 1.23 million prefixes: the journal already gives the kernel task only the latest change of a prefix when it lags, so no further coalescing of installs is called for. Documentation: `expected_routes` in the configuration reference, the neighbor guide and the proto comment say that the table is sized by it; the testing guide's VM results are brought up to date. Testing: a table test checks that the room is there and is kept; the workspace tests pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Documentation sources
This directory holds the sources of the Ferrix documentation site, built with Zola:
zola --root docs serve # http://127.0.0.1:1111, rebuilt on every change
zola --root docs build # into docs/public
The pages under content/ are Markdown with Zola additions, which a code
forge does not render:
- The block between
+++lines at the top of each page is its front matter: the title, description and position in the navigation. {{ example(name="...") }}and{{ file(name="...") }}insert a file fromexamples/, whole, at that point. Open the file to read it.- Links of the form
@/docs/...are internal links that Zola resolves and checks at build time. On the forge they do not work; the target is the path after@/, undercontent/.
To read the documentation as intended, build the site, or read it where
it is published (base_url in config.toml).
STYLE.md is the writing guide. CI builds the site on every push and fails
on a link to a page or an anchor that does not exist; zola --root docs check also checks external links.