[PATCH grout] add high-performance clock

[Robin Jarry]

Morten Brørup, Jun 11, 2026 at 11:26:
>> This means gr_clock_ns() values returned in API messages by the grout
>> daemon cannot be compared with values returned in grout clients (e.g.
>> grcli).
>> 
>> It will break commands that display time differences such as:
>> 
>> $ grcli fdb show
>> 
>> https://github.com/DPDK/grout/blob/v0.16.0/modules/l2/cli/fdb.c#L141
>> 
>> $ grcli conntrack show
>> 
>> https://github.com/DPDK/grout/blob/v0.16.0/modules/policy/cli/conntrack
>> .c#L58
>> 
>
> Good point.
>
> I will try to make the API integrate deeper, so Grout clients can
> somehow determine the clock the same way as Grout itself.
>
> I strongly prefer that Grout's dataplane is able to base its high-res
> clock on rte_rdtsc(), because it executes more than an order of
> magnitude faster than clock_gettime(CLOCK_MONOTONIC_RAW).
>
> I have seen clock_gettime(CLOCK_MONOTONIC_RAW) execution times of
> 400-700 CPU cycles.
>
> For comparison, rte_rdtsc() only takes ca. 40 CPU cycles, inclusive
> the conversion to nanoseconds.

I will reply on the other emails you sent.

>> >  	for (;;) {
>> > +		clock_update();
>> 
>> Could you move clock_update() inside the housekeeping block? I don't
>> think we need more precision that once every 256 rounds of graph
>> walk.
>
> The way it's used now, it could move to housekeeping, yes. But I plan
> to call it much more frequently in the future, maybe even inside some
> graph nodes.
>
> So I prefer to keep it here, to highlight that it is intended for
> being called very often.

OK, if it only involves calling rte_rdtsc() it is fine then.

-- 
Robin

> Space is limited.