On Wed, 21 Jan 2026 18:01:17 +0100 [email protected] wrote: > From: Martin Spinler <[email protected]> > > The resulting timestamp wasn't monotonically increasing value. > > Now the timestamp is value in nanoseconds (Unix epoch). > > Unfortunately there's currently no safe mechanism in nfb-framework > to get ticks from hardware to implement read_clock function. > > Signed-off-by: Martin Spinler <[email protected]> > --- > doc/guides/nics/nfb.rst | 6 ++---- > drivers/net/nfb/nfb_rx.h | 13 +++++++------ > 2 files changed, 9 insertions(+), 10 deletions(-)
The patch is ok as far as it goes. But the best practice in DPDK for drivers doing timestamps is for the driver to only put a timestamp on if timestamp offload flag was set when configuring that device. For the case of multiple devices that means that one device may have timestamp and other not. Also any driver that supports receive timestamp must provide a read_clock operation. Otherwise the application has no way of knowing what units the timestamp is in. I added that to the AI review script so new drivers will get rejected with out it. I suspect that in this drivers case it is only used in systems where: - only single instance of device is possible - your application is just assuming a common unit like nanosecond.
