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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox