[wishes/any Bug 1929] Ethdev Tx Completion API

[bugzilla at dpdk.org]

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: dev at dpdk.org
          Reporter: mb at 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.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.