Index | Thread | Search

From:
Theo Buehler <tb@theobuehler.org>
Subject:
Re: bgpd: implement rib prefix pending queue
To:
Claudio Jeker <cjeker@diehard.n-r-g.com>
Cc:
tech@openbsd.org
Date:
Thu, 2 Jul 2026 07:53:21 +0200

Download raw body.

Thread
On Wed, Jul 01, 2026 at 07:59:16PM +0200, Claudio Jeker wrote:
> Next small step towards optimising add-path send.
> 
> This implements the actually pending prefix queue in struct re_entry.
> Elements are added to the queue and the queue is flushed once processed.
> Nothing is currently using this data. This will follow next.
> 
> Right now this uses a simple TAILQ. It is hard to estimate if this
> is good enough or a better structure is needed. Only profiling this on
> some large setups will give us the proper insights.
> 
> Prefixes / paths are added to the queue and replaced on every update.
> Once peer_process_updates() runs for a given rib entry the queue is
> flushed.  In rib_remove() we just check that the queue is actually empty.
> This should be implied by the re_is_queued() checked a bit earlier but
> lets be sure.

ok tb

One typo in code that was moved:

> Index: rde_rib.c
[...]
> +void
> +rib_pq_enqueue(struct rib_entry *re, struct rde_peer *peer,
> +    uint32_t path_id_tx, struct prefix *p)
> +{
[...]
> +	/*
> +	 * Enqueue only once, may need some reconsideration if queue
> +	 * length of individual peers becomes excessivly long.

excessivly -> excessively