From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 609A2C61DC6 for ; Thu, 27 Aug 2026 12:13:46 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87D5B40276; Thu, 27 Aug 2026 14:13:45 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by mails.dpdk.org (Postfix) with ESMTP id 211EC4003C for ; Thu, 27 Aug 2026 14:13:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1787832824; x=1819368824; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kJ9b9znC5Ao517bGqW/9wRtJXe11X/AXTaokY762hGA=; b=XjAor5oYJm8jgchkabvBc2tV4LyHf/goiotFli6t2sCS67ZTFQlzbJWB 1yC/bQsRW5PQsrrHLeZwJqo3fOrgCGRUfY7HVfB9FxII7czc8aS25sn7A wSm+wR0JDft3lL/JGOYBiC7DRRsZuTS7U5IzXuV5KY/CeEo5VN58iTMFK UW9PVBfgWo2Xar8bS82Aul3/FPj/zSNv6IFIxQgObIRlrOlPAe7HydyHR IIWwrdx2Rz/y6Rf3MSRbikTcrqYAvY59AGQBcmB6ANZz0T3c6hUMgxCmr QiogQl9tA/7PntPvd2BiPRDUf8QenPaQxCJoLeK/RK2C84QN1VWHbKQe8 g==; X-CSE-ConnectionGUID: nJsrpEgpSJaSXUwbCPWqiA== X-CSE-MsgGUID: sg59d2dBTfiYuXJOFouwuw== X-IronPort-AV: E=McAfee;i="6800,10657,11887"; a="92015876" X-IronPort-AV: E=Sophos;i="6.25,246,1779174000"; d="scan'208";a="92015876" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Aug 2026 05:13:43 -0700 X-CSE-ConnectionGUID: 7AeNabgfRHiXMO3UrA1kOw== X-CSE-MsgGUID: Gxt81u33S9elvkJeBC9T2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,246,1779174000"; d="scan'208";a="264083424" Received: from unknown (HELO icx008-fc43.iind.intel.com) ([10.190.212.196]) by fmviesa010.fm.intel.com with ESMTP; 27 Aug 2026 05:13:41 -0700 From: Rajesh Kumar 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 Subject: [RFC PATCH v2 0/1] ethdev: add Tx timestamp slot APIs Date: Thu, 27 Aug 2026 17:43:35 +0530 Message-ID: <20260827121337.338720-1-rajesh3.kumar@intel.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260817192417.3009990-1-rajesh3.kumar@intel.com> References: <20260817192417.3009990-1-rajesh3.kumar@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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