From: Rajesh Kumar <rajesh3.kumar@intel.com>
To: dev@dpdk.org
Cc: thomas@monjalon.net, bruce.richardson@intel.com,
andrew.rybchenko@oktetlabs.ru,
Rajesh Kumar <rajesh3.kumar@intel.com>
Subject: [RFC 0/1] ethdev: per-packet Tx timestamp slot management
Date: Tue, 18 Aug 2026 00:54:14 +0530 [thread overview]
Message-ID: <20260817192417.3009990-1-rajesh3.kumar@intel.com> (raw)
The current DPDK ethdev time synchronization framework is architected
around a single, shared hardware latch. The existing API,
`rte_eth_timesync_read_tx_timestamp()`, assumes a serialization model
where only one TX timestamp is outstanding at any given time.
This model creates severe limitations for modern high-throughput network
interface cards (NICs). When multiple packets requiring precise
transmit timestamps are sent concurrently, the shared latch becomes a
race-condition bottleneck. It makes timestamp retrieval unreliable and
drops accuracy. Furthermore, Poll Mode Drivers (PMDs) backed by
hardware that supports independent, per-packet timestamping slots have
no way to expose this capability to the user.
To solve this, this RFC introduces a formal slot-based lifecycle API
for per-packet Tx timestamp management. The API decouples timestamp
tracking from the global latch model, enabling true asynchronous,
parallel hardware timestamping.
Key Components of the Proposal:
================================
1. **Slot Lifecycle Management APIs**:
- `rte_eth_timesync_tx_timestamp_slot_alloc()`: Allocates and locks
a unique hardware slot prior to frame transmission.
- `rte_eth_timesync_tx_timestamp_stamp_mbuf()`: Embeds the allocated
slot handle into an mbuf dynamic field, allowing the PMD to
program the specific hardware descriptor during the Tx burst.
- `rte_eth_timesync_read_tx_timestamp_slot()`: Asynchronously polls
a specific slot for its captured value, safely returning `-EAGAIN`
if the hardware has not yet written back the timestamp.
- `rte_eth_timesync_tx_timestamp_slot_release()`: Recycles the
hardware slot back to the PMD resource pool after successful
retrieval or an application timeout.
2. **Dual-Domain Timing Mechanics**:
- Introduces `struct rte_eth_timesync_dual_domain_timestamp` to
simultaneously capture both the adjusted PTP Hardware Clock (PHC)
domain (`adjusted_ns`) and the raw, free-running cycles domain
(`cycles_ns`).
- A dedicated `valid_mask` tracks the validity of each time domain
independently, giving applications granular telemetry options.
Scope of this RFC & Open Questions for the Community:
======================================================
This RFC establishes the structural definition of the APIs and driver
interfaces. Before proceeding to a full `v1` patch with active PMD
implementations, we would highly appreciate the community's feedback
on the following design choices:
- **Mbuf Dynamic Field Layout**: Is the encapsulation of the slot
handle into an mbuf dynamic field using standard dynamic registration
the preferred mechanism for passing steering context to the Tx
descriptor path?
- **Dual-Domain Structure**: Does tracking both the adjusted PHC and
the cycle counter within `rte_eth_timesync_dual_domain_timestamp`
cover the needs of other hardware vendors supporting concurrent
domains?
- **Error States**: Is `-EAGAIN` an acceptable return code for
non-blocking polling of incomplete timestamps, or should we consider
an explicit bitmask status?
Please review the proposed design. We welcome your feedback, design
suggestions, and critique.
Rajesh Kumar (1):
ethdev: add per-packet Tx timestamp slot APIs
lib/ethdev/ethdev_driver.h | 19 ++++++
lib/ethdev/rte_ethdev.c | 121 +++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 108 +++++++++++++++++++++++++++++++++
3 files changed, 248 insertions(+)
--
2.54.0
next reply other threads:[~2026-08-17 19:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 19:24 Rajesh Kumar [this message]
2026-08-17 19:24 ` [RFC 1/1] ethdev: add per-packet Tx timestamp slot APIs Rajesh Kumar
2026-08-18 2:23 ` [RFC 0/1] ethdev: per-packet Tx timestamp slot management Stephen Hemminger
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=20260817192417.3009990-1-rajesh3.kumar@intel.com \
--to=rajesh3.kumar@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.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.