CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2025/12/28 10:52:44
Modified files:
usr.sbin/bgpd : rde.c rde.h rde_peer.c rde_rib.c
Log message:
Introduce a rib entry queue used to split the processing of UPDATES into
two steps.
One of the biggest latency inducing bottlenecks in bgpd is that UPDATE
messages are processed to completion. Updating the Adj-Rib-Out is a
loop over all peers and is therefor super heavy. By taking this part
of the pipeline into its own step we can drop the latency inside the
main poll loop by a lot.
Introduce a per-peer update queue that enqueues the rib entries after
the decision process and then handles those one by one. This also has
a benefit that a single peer can not monopolize the processing in bgpd.
So a single flapping peer should result in far less noticeable delays
on all other UPDATES from other peers.
For now disable the "addpath send all" optimisation since for that
an extra queue of updates needs to be kept. Instead just use the regular
addpath codepath that is less optimised but produces the same results.
With and OK tb@
