Ethdev Tx Completion API

http://bugs.dpdk.org/show_bug.cgi?id=1929

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: [email protected]
Reporter: [email protected]
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.1Qbb 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 delays 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 reflect the timing of the report and not actual tx time.
This flag can be enabled via both socket options and control messages."

You are receiving this mail because:
You are the assignee for the bug.