On Mon, 12 Oct 2026 10:50:19 +0000
Tathagat Priyadarshi <[email protected]> wrote:

> This patch series aligns the Google Virtual NIC (gve) DQO RDA transmit path
> with the upstream Linux kernel driver (drivers/net/ethernet/google/gve/) to
> resolve transmit queue stalls and hardware validation issues:
> 
> 1. net/gve: fix DQO descriptor cleaning loop bound
>    Fixes the off-by-one error in gve_tx_clean_descs_dqo()
>    ("while (--nb_descs)" -> "while (nb_descs--)") and avoids stalling
>    the completion queue on unrecognized descriptor types.
> 
> 2. net/gve: fix DQO TX queue stall on multi-seg and TSO
>    Tracks descriptor intervals with last_re_idx per packet against
>    GVE_TX_MIN_RE_INTERVAL (32) instead of counting packets at burst end,
>    preventing descriptor ring starvation and queue deadlocks under
>    multi-segment and TSO traffic.
> 
> 3. net/gve: add cacheline overlap margin to DQO TX ring
>    Enforces GVE_TX_MIN_DESC_PREVENT_CACHE_OVERLAP (4 descriptors) margin
>    in ring space checks, avoiding CPU and device DMA cacheline collisions.
> 
> 4. net/gve: add packet and TSO hardware constraints for DQO
>    Augments gve_tx_validate_descs() (which enforces the 10-descriptor
>    limit per packet or MTU segment) with the remaining hardware length
>    constraints: [17, 9728] bytes for non-TSO packets, maximum MSS limit
>    (9728 bytes) to avoid 14-bit field wrap-around, and validates header
>    contiguity and payload presence on TSO packets.
> 
> Tathagat Priyadarshi (4):
>   net/gve: fix DQO descriptor cleaning loop bound
>   net/gve: fix DQO TX queue stall on multi-seg and TSO
>   net/gve: add cacheline overlap margin to DQO TX ring
>   net/gve: add packet and TSO hardware constraints for DQO
> 
>  drivers/net/gve/base/gve_desc_dqo.h |  3 ++
>  drivers/net/gve/gve_ethdev.h        |  2 +-
>  drivers/net/gve/gve_tx_dqo.c        | 80 +++++++++++++++++++++--------
>  3 files changed, 62 insertions(+), 23 deletions(-)

The problem with the series is in the last patch.
The way tx_burst works the driver has to consume packets that cause
errors.

Subject: Re: [PATCH 0/4] net/gve: DQO Tx fixes

Applies cleanly to main; every commit builds with -Dwerror=true.
Patches 1-3 match the Linux gve driver (unknown completion types are
skipped, report_event spaced by descriptor index, 4 descriptor
cacheline margin).

Errors

[PATCH 4/4] net/gve: add packet and TSO hardware constraints for DQO

1. An invalid packet stalls the queue instead of being dropped.

       if (!gve_tx_validate_descs(tx_pkt, nb_descs, tso)) {
               txq->stats.too_many_descs++;
               break;
       }

   tx_burst returns short, so the application gets the bad mbuf back
   and retries it at the head of the next burst. It is rejected again,
   and nothing behind it is ever sent. The break was already there for
   the descriptor limit; this patch extends it to runts, oversize
   frames, bad MSS, split headers and zero length, all per-packet
   errors. A short return should mean only ring full. Linux frees the
   skb and returns NETDEV_TX_OK for the same checks.

   Validate before the ring space check, then free and continue:

       nb_descs = gve_tx_pkt_nb_data_descs(tx_pkt);
       nb_descs += tso;

       /* Drop packet if it doesn't adhere to hardware limits. */
       if (unlikely(!gve_tx_validate_descs(tx_pkt, nb_descs, tso))) {
               txq->stats.too_many_descs++;
               rte_pktmbuf_free(tx_pkt);
               nb_drop++;
               continue;
       }

       req_descs = nb_descs + GVE_TX_MIN_DESC_PREVENT_CACHE_OVERLAP;
       ...

   and use nb_tx - nb_drop for stats.packets. too_many_descs now counts
   more than descriptor overruns; renaming it, or adding a drop
   counter, would make the xstat less misleading. The rte_mbuf_check()
   failure just above has the same break and needs the same fix.

Info

[PATCH 4/4] net/gve: add packet and TSO hardware constraints for DQO

2. The non-TSO length check fixes the original DQO Tx path, not TSO
   support. Add:

   Fixes: 4022f9999f56 ("net/gve: support basic Tx data path for DQO")

Reply via email to