bgpd: carry reception time at microsecond precision in BMP adj-in

[tobez]

BMP Route Monitoring per-peer header timestamps are reconstituted from a
seconds-only monotonic time_t, so monotime_to_realtime() fills the
microsecond field with the sub-second offset between CLOCK_REALTIME and
CLOCK_MONOTONIC -- a boot-constant value, identical in every RM message
until the host reboots.

For the pre-policy (Adj-RIB-In) feed full precision is free: the
reception time lives in struct bgp_adj_in, written in one place and read
only by BMP. Store the microseconds in the struct's padding hole (no
size growth on LP64), stamp both fields from one clock read in
bgp_adj_in_set(), and pass bmp_monitor() a monotonic struct timeval,
NULL meaning "time unavailable" in place of the (time_t)(-1L) sentinel.

Post-policy, Loc-RIB and peer-state timestamps intentionally stay
second-precision: their sources are shared time_t fields used across
bgpd.

Includes a topotest asserting that the microsecond components of
pre-policy updates received seconds apart actually differ.

[greptile-apps]

Greptile Summary

This PR preserves microsecond precision for pre-policy BMP Route Monitoring timestamps by storing the complete monotonic Adj-RIB-In reception time and passing nullable timeval values through BMP timestamp conversion.

• Adds a microsecond field to struct bgp_adj_in and stamps seconds and microseconds from one monotonic clock read.
• Changes bmp_monitor() from a time_t sentinel interface to a nullable struct timeval interface.
• Preserves existing second-resolution behavior for post-policy and Loc-RIB timestamps.
• Adds a topotest that distinguishes genuine reception microseconds from the prior boot-constant conversion artifact.

Confidence Score: 5/5

The PR appears safe to merge, with the intended pre-policy timestamp precision preserved through every changed storage and BMP emission path.

Adj-RIB-In timestamps are captured atomically, all consumers initialize the complete timeval, unavailable timestamps retain their previous zero encoding, and no blocking behavioral or contract failure remains.

Important Files Changed

Filename	Overview
bgpd/bgp_advertise.c	Captures one monotonic timeval and consistently stores both components for new and updated Adj-RIB-In entries.
bgpd/bgp_advertise.h	Adds microsecond storage without introducing a serialization or binary-layout dependency.
bgpd/bgp_bmp.c	Converts bmp_monitor() to a nullable timeval contract while preserving previous missing-time and seconds-only behavior at all callers.
tests/topotests/bgp_bmp/test_bgp_bmp_timestamps.py	Adds coverage proving that pre-policy timestamps carry varying reception-time microseconds across re-announcements.

Sequence Diagram

sequenceDiagram
    participant BGP as BGP update processing
    participant Adj as Adj-RIB-In
    participant BMP as BMP monitor
    participant C as BMP collector
    BGP->>BGP: "monotime(&now)"
    BGP->>Adj: store now.tv_sec and now.tv_usec
    Adj->>BMP: pass monotonic timeval
    BMP->>BMP: monotime_to_realtime()
    BMP->>C: Route Monitoring header with sec/usec

Loading

_{Reviews (1): Last reviewed commit: "tests: check BMP pre-policy timestamps c..." | Re-trigger Greptile}

[tobez]

ci:rerun

[tobez]

ci:rerun

[tobez]

ci:rerun

[ton31337]

What if we change time_t to struct timeval adj->uptime at all? This way we could avoid having adj->uptime_usec?

[tobez]

What if we change time_t to struct timeval adj->uptime at all? This way we could avoid having adj->uptime_usec?

It would be cleaner but we'll pay for that in memory per entry. The 4-byte uptime_usec in the PR fits into a padding hole, so the struct size stays at 56 bytes (which incidentally is at the limit of 64-bit glibc usable chunk size. Replacing it all with timeval (2 x 8 bytes) would mean addpath_rx_id will still need padding, so the struct becomes 64 bytes, and the next usable chunk is 72 bytes. So we would be paying 16 byte penalty for each entry. (Clearly, all this is applicable for LP64 architecture with glibc, but that's probably the vast majority of all installs).

[riw777]

looks good

[ton31337]

TL;DR: IMO, I prefer maintainability here (using struct timeval) versus adding an additional uptime_usec for struct bgp_adj_in.

That's eventually 8-bytes more, but still it's under the same 64 bytes "bucket", 56 (by filling padding gap) versus 64 with the timeval struct. And since it's very small in general (we are not going e.g. from 1 to 2 cache lines by adding timeval, I prefer maintainability. (It's just my opinion, might be wrong completely, sorry, and I'd like to ask @donaldsharp and @eqvinox opinions also).