[PATCH v2 0/6] net/gve: add hardware timestamping support

[Mark Blasko]

On Sun, May 17, 2026 at 4:15 PM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> Warning: (unchanged from v1) gve_read_clock and the periodic
> gve_read_nic_clock alarm callback both issue
> GVE_ADMINQ_REPORT_NIC_TIMESTAMP into the single shared DMA buffer
> priv->nic_ts_report, then read it after gve_adminq_execute_cmd
> has released adminq_lock. If gve_read_clock is preempted between
> gve_adminq_report_nic_timestamp returning and the be64_to_cpu
> read, the alarm callback can memset() and reissue its own
> command, so the user thread will read either zero or another
> command's response. The simplest fix is for gve_read_clock to
> return the cached priv->last_read_nic_timestamp instead of
> issuing a fresh adminq command - the 250ms periodic sync keeps
> it fresh enough for .read_clock semantics. Once the dev_op
> registration is restored this race becomes reachable.

I want to make sure I fully understand the API contract here. Is the
fact that .read_clock does not require a fresh device read documented
in the DPDK specification, or is this based on typical application
use cases? If the latter, what are those typical use cases?