From: Rajesh Kumar <rajesh3.kumar@intel.com>
To: dev@dpdk.org
Cc: thomas@monjalon.net, bruce.richardson@intel.com,
andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org,
aman.deep.singh@intel.com, Rajesh Kumar <rajesh3.kumar@intel.com>
Subject: [RFC PATCH v3 0/1] ethdev: add Tx timestamp slot APIs
Date: Thu, 27 Aug 2026 17:51:58 +0530 [thread overview]
Message-ID: <20260827122200.339388-1-rajesh3.kumar@intel.com> (raw)
In-Reply-To: <20260817192417.3009990-1-rajesh3.kumar@intel.com>
The ethdev timesync API currently exposes Tx timestamps through a shared
hardware register. This requires applications to serialize timestamped
packets and does not allow correlation when multiple packets are in
flight.
This RFC proposes an ethdev interface for hardware with independent Tx
timestamp slots. The interface reports the supported timestamping
mechanism, provides a port-global slot lifecycle, and lets applications
poll each slot asynchronously after transmission.
The proposal includes the following components:
* Capability reporting for shared-register and per-packet timestamping.
* Slot allocation, asynchronous timestamp retrieval, and slot release.
* A dual-domain timestamp structure for adjusted PHC and raw hardware
time.
* Mbuf dynamic field and dynflag support for passing slot handles to Tx.
* Registration and process-local disabling of slot metadata.
* A compatibility alias for the mbuf stamping helper.
* Programmer-guide and NIC feature documentation.
The legacy rte_eth_timesync_read_tx_timestamp() API remains available on
devices using a shared timestamp register. This RFC adds the ethdev and
PMD interfaces but does not add a hardware-specific PMD implementation.
The following areas would benefit from review:
* Is the capability model sufficient for devices with different slot
allocation or completion mechanisms?
* Is an mbuf dynamic field and dynflag the appropriate way to pass the
slot handle into the Tx datapath?
* Is -EAGAIN the appropriate result while a slot timestamp is pending?
* Should the adjusted and raw timestamp domains use nanoseconds in the
public structure, or should one domain expose hardware cycles instead?
Rajesh Kumar (1):
ethdev: add Tx timestamp slot management APIs
doc/guides/nics/features.rst | 16 +-
doc/guides/prog_guide/ethdev/index.rst | 1 +
doc/guides/prog_guide/ethdev/timesync.rst | 217 +++++++++++++++++++
doc/guides/rel_notes/release_26_11.rst | 7 +
lib/ethdev/ethdev_driver.h | 25 +++
lib/ethdev/rte_ethdev.c | 158 ++++++++++++++
lib/ethdev/rte_ethdev.h | 242 ++++++++++++++++++++++
7 files changed, 662 insertions(+), 4 deletions(-)
create mode 100644 doc/guides/prog_guide/ethdev/timesync.rst
--
2.55.0
next prev parent reply other threads:[~2026-08-27 12:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 19:24 [RFC 0/1] ethdev: per-packet Tx timestamp slot management Rajesh Kumar
2026-08-17 19:24 ` [RFC 1/1] ethdev: add per-packet Tx timestamp slot APIs Rajesh Kumar
2026-08-20 4:51 ` Naga Harish K, S V
2026-08-18 2:23 ` [RFC 0/1] ethdev: per-packet Tx timestamp slot management Stephen Hemminger
2026-08-20 4:41 ` Naga Harish K, S V
2026-08-27 11:09 ` Kumar, Rajesh
2026-08-27 12:13 ` [RFC PATCH v2 0/1] ethdev: add Tx timestamp slot APIs Rajesh Kumar
2026-08-27 12:13 ` [RFC PATCH v3 1/1] ethdev: add Tx timestamp slot management APIs Rajesh Kumar
2026-08-27 12:18 ` [RFC PATCH v3 0/1] ethdev: add Tx timestamp slot APIs Rajesh Kumar
2026-08-27 12:21 ` Rajesh Kumar [this message]
2026-08-27 12:21 ` [RFC PATCH v3 1/1] ethdev: add Tx timestamp slot management APIs Rajesh Kumar
2026-08-27 21:45 ` Stephen Hemminger
2026-08-27 12:34 ` [RFC PATCH v2 0/1] ethdev: add Tx timestamp slot APIs Rajesh Kumar
2026-08-27 12:34 ` [RFC PATCH v2 1/1] ethdev: add Tx timestamp slot management APIs Rajesh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260827122200.339388-1-rajesh3.kumar@intel.com \
--to=rajesh3.kumar@intel.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.