Re: [v8,0/4] net/zxdh: optimize Rx/Tx path performance

[Junlong Wang <wang.junlong1@zte.com.cn>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2231 bytes --]

> [PATCH v8 4/4] net/zxdh: optimize Tx xmit pkts performance
> 
> Error: the simple Tx burst signals a bad packet with a short return,
> which the application cannot distinguish from backpressure.

>     for (i = 0; i < nb_pkts; i++) {
>         rte_prefetch0(tx_pkts[i]);
>         if (unlikely(tx_pkts[i]->data_off < hdr_len)) {
>             txvq->stats.errors += nb_pkts - i;
>             nb_pkts = i;
>             break;
>         }
>     }
> 
> A short return from tx_burst is the backpressure signal (transmit ring
> full, retry later). Here it is also used to mean "packet i is bad",
> and the bad mbuf is left owned by the caller. The application has no
> way to tell the two apart: the usual
> 
>     for (sent = 0; sent < n; )
>         sent += rte_eth_tx_burst(port, q, &pkts[sent], n - sent);
> 
> loop treats the short return as backpressure and resubmits pkts[i],
> which fails again every time -- head-of-line blocking, and the good
> packets after i (which had ring space) never go out.
> 
> A packet that cannot be sent must be consumed by the driver, not
> handed back. Free it in tx_burst, increment the tx error counter, and
> continue with the rest of the burst. For a burst of 16 where only
> index 3 is bad and the ring has room, tx_burst should return 16, with
> stats showing 15 transmitted and 1 tx error. A short return is then
> reserved for the one case the application is entitled to retry: ring
> full.

The design intent of zxdh_xmit_pkts_simple is a fast path with
a usage restriction, not a general Tx entry point.
The restriction is data_off >= hdr_len on single-segment
mbufs. When a packet violates the restriction, the function
exits without sending — that is the contract, not a bug.

Applications that may produce reduced-headroom mbufs are
expected to keep RTE_ETH_TX_OFFLOAD_MULTI_SEGS enabled, in
which case zxdh_xmit_pkts_packed is selected instead and
handles the full set of inputs. The split between the two
paths is intentional.

how about add a paragraph to the "Limitations or Known issues"
section of doc/guides/nics/zxdh.rst describing the fast path's
requirement and pointing at the packed path as the alternative.

Thanks.

[-- Attachment #1.1.2: Type: text/html , Size: 4630 bytes --]