rib: size the routing table for the routes the peers are expected to send

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>

docs/content/docs/development/testing.md

@@ -240,13 +240,14 @@ prefixes.
 
 | Measurement | Result |
 |---|---|
-| One neighbor; routes in the routing table | 0.7 seconds, 1.7 million routes per second |
+| One neighbor; routes in the routing table | 0.8 seconds, 1.5 million routes per second |
 | One neighbor; the best routes installed in the kernel | 2.0 seconds after the first route |
 | One neighbor, without the kernel; routes in the routing table | 0.6 seconds, 2.0 million routes per second |
-| Four neighbors; 4.92 million routes in the routing table | 1.1 seconds, 4.5 million routes per second |
-| Four neighbors; the best routes installed in the kernel | 3.0 seconds after the first route |
-| Resident memory with one neighbor's table installed | 520 MB |
-| Resident memory with four neighbors' tables installed | 680 MB |
+| Four neighbors; 4.92 million routes in the routing table | 1.1 seconds, 4.4 million routes per second |
+| Four neighbors; the best routes installed in the kernel | 2.2 seconds after the first route |
+| Four neighbors; routes the kernel was asked to install | 1.25 million, for 1.23 million prefixes |
+| Resident memory with one neighbor's table installed | 440 MB |
+| Resident memory with four neighbors' tables installed | 630 MB |
 
 A session is processed on one thread, so one neighbor's table arrives at
 the rate of one CPU core, and several neighbors' tables arrive in

docs/content/docs/guides/peers.md

@@ -259,8 +259,11 @@ with this value. An established session with fewer than half the expected
 routes is listed under **Needing attention**, with the expected number
 beside the actual one. The comparison starts one minute after the session
 is established, so that a neighbor that is still sending its table is not
-reported. The value does not affect route processing; `max_prefixes` is
-the limit that Ferrix enforces.
+reported. The value does not affect which routes are accepted;
+`max_prefixes` is the limit that Ferrix enforces. Ferrix also sizes the
+routing table at startup for the largest `expected_routes` value among
+the neighbors, so that the table does not grow while the tables are
+received.
 
 ## Verifying BGP Sessions
 

docs/content/docs/reference/configuration.md

@@ -77,7 +77,7 @@ Statements for a BGP neighbor.
 | `role` <span class="type">[Role](#role)</span> | None | Specifies the BGP role of the neighbor (RFC 9234). Not permitted for IBGP neighbors. Required for every EBGP neighbor if any `export` statement enables `learned_routes`. |
 | `require_role` <span class="type">bool</span> | `false` | Rejects the session if the neighbor does not advertise a BGP role. Requires `role`. |
 | `passive` <span class="type">bool</span> | `false` | Prevents Ferrix from initiating connections to the neighbor. Ferrix accepts connections from the address of `endpoint`; the port of `endpoint` is not used. See [Passive Neighbors](@/docs/guides/peers.md#passive-neighbors). |
-| `expected_routes` <span class="type">uint32</span> | 0 | Specifies the approximate number of routes that the neighbor advertises in normal operation. The status page marks an established session with fewer than half this number of routes as needing attention. The value does not affect route processing. 0 disables the comparison. See [Expected Route Counts](@/docs/guides/peers.md#expected-route-counts). |
+| `expected_routes` <span class="type">uint32</span> | 0 | Specifies the approximate number of routes that the neighbor advertises in normal operation. The status page marks an established session with fewer than half this number of routes as needing attention. Ferrix also allocates the routing table with room for the largest `expected_routes` value among the neighbors at startup, which avoids the table growing, and briefly using twice its memory, while the tables are received. The value does not affect which routes are accepted. 0 disables the comparison. See [Expected Route Counts](@/docs/guides/peers.md#expected-route-counts). |
 | `export` <span class="type">[ExportPolicy](#exportpolicy)</span> | Top-level `export` | Specifies the export policy for the neighbor. Replaces the top-level `export` statement. |
 | `graceful_restart` <span class="type">[GracefulRestart](#gracefulrestart)</span> | Top-level `graceful_restart` | Specifies graceful restart for the neighbor. Each statement that is set replaces the corresponding top-level statement. |
 | `route_reflector_client` <span class="type">bool</span> | `false` | Makes the IBGP neighbor a route reflector client: Ferrix advertises to it the routes learned from other IBGP neighbors, and advertises its routes to them. Permitted only for IBGP neighbors. See [Route Reflection](@/docs/guides/passing-routes-on.md#route-reflection). |