[PATCH grout] add high-performance clock

[Robin Jarry]

Hey Morten,

Morten Brørup, Jun 12, 2026 at 20:45:
> I really want a high-performance clock in Grout.
>
> And since the rte_rdtsc() clock is out of sync with any system wide
> clock, e.g. CLOCK_MONOTONIC_RAW, I am making the clock private to
> Grout, and exposing an API for other processes to read it.
>
> This also means that gr_clock_ns() is no longer available as a generic
> utility function for other processes. (I.e. it cannot be used for
> profiling in smoke/fib_inject.c or for random generator seeding in
> cli/main.c, so I have fixed both of these.)
>
> The gr_clock_ns() function has become a client API that reads the
> clock from the Grout process.
>
> So far, so good!
>
> Now, I'm unsure about where the new clock API and API "implementation"
> should go.
>
> So I am asking for guidance on this.
>
> For now, there is only one API function, "gr_clock_ns_t
> gr_clock_ns(struct gr_api_client *);".
>
> I have put it in gr_clock.h as an inline function, but is that the
> right place?
>
> Should I make it non-inline and add the implementation to
> gr_api_client_impl.h?
>
> And should I move the clock module stuff from gr_clock.h to gr_api.h?
>
> The "clock" module seems essential, and not really an "infra" module,
> so I have put it in the main/ directory rather than under
> modules/infra/. Is that wrong? Should I just consider the "clock"
> module an "infra" module, and move everything there?

I think you should leave gr_clock.h as it is currently (calling
clock_gettime(CLOCK_MONOTONIC_RAW)). Having an API message to "get
current time" is not a good idea.

The only thing needed is to ensure that datapath workers don't call
gr_clock_ns() directly. Instead, they should call rte_rdtsc() and the
conversion to clock_gettime(CLOCK_MONOTONIC_RAW) compatible values
should only be done on the API border (i.e. when writing values on the
API socket for clients consumption). That way, gr_clock_ns() can be used
transparently.

As I understand, rte_rdtsc() values are not thread dependent and can be
compared regardless from which thread they were computed. That means
that the only thing you need to do is sample the value of gr_clock_ns()
and rte_rdtsc() on program startup:

	rte_eal_init(...);
	...
	gr_clock_ns_t clock_epoch = gr_clock_ns();
	uint64_t tsc_epoch = rte_rdtsc();

And then, do a conversion when exporting objects that expose
gr_clock_ns_t timestamps:

	double factor = (double)(gr_clock_ns() - clock_epoch) /
			(double)(rte_rdtsc() - tsc_epoch);

	pub->timestamp = priv->timestamp * factor;

No special API message needed. Timestamps are valid from the user point
of view and can be compared with gr_clock_ns() values.

What do you think?

-- 
Robin

> Not valid with other offers or specials.