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 1FD72E88D66 for ; Sat, 4 Apr 2026 10:28:38 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9F1E40287; Sat, 4 Apr 2026 12:28:37 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 7BDFF40281 for ; Sat, 4 Apr 2026 12:28:36 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 63A304AE25; Sat, 4 Apr 2026 12:28:36 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [wishes/any Bug 1929] Ethdev Tx Completion API Date: Sat, 04 Apr 2026 10:28:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: wishes X-Bugzilla-Component: any X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: mb@smartsharesystems.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone bug_group Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 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 http://bugs.dpdk.org/show_bug.cgi?id=3D1929 Bug ID: 1929 Summary: Ethdev Tx Completion API Product: wishes Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: any Assignee: dev@dpdk.org Reporter: mb@smartsharesystems.com Target Milestone: --- Group: wishes-managers The Ethdev API lacks the ability to provide information about what happened= to a packet after it was passed on to an ethdev driver via rte_eth_tx_burst(): 1. Did the driver actually transmit the packet on the wire, or did it drop = the packet (due to link down or some other reason)? 2. When (timestamp) was the packet actually transmitted on the wire (delays caused by a long Tx descriptor queue, hardware scheduling, or 802.3x/802.1Q= bb flow control)? As a hack, the application could increase the refcnt of the mbufs before passing them on to the driver, and poll rte_eth_tx_done_cleanup() to monitor when the refcnt was decreased. That would provide a Tx timestamp with an accuracy depending on the tx_done_cleanup() poll frequency. But it doesn't tell if the packet was dropped or sent by the driver. Also, it doesn't show what actually went out on the wire in case of hardware assisted Tx Segmentation Offload, where the hardware splits a large packet = into multiple smaller packets. But I'm not concerned about that, because the application can compensate for it. A new Ethdev API for Tx Completion would be useful for multiple purposes: * For packet capture. A capture file containing all packets passed on to the driver is not trustworthy if it includes unsent packets. * For queue management. Information about packet transmission queueing dela= ys is relevant for queue management, ECN marking, CoDel, L4S, etc. It is also imaginable that application level congestion control algorithms could make = use of such information. For reference, Linux has SOF_TIMESTAMPING_TX_COMPLETION: "Request tx timestamps on packet tx completion. The completion timestamp is generated by the kernel when it receives packet= a completion report from the hardware. Hardware may report multiple packets at once, and completion timestamps ref= lect the timing of the report and not actual tx time. This flag can be enabled via both socket options and control messages." --=20 You are receiving this mail because: You are the assignee for the bug.=