Re: [PATCH v2 0/4] net/gve: TSO descriptor count fixes for GVE DQO

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 30 Oct 2026 11:42:59 -0700
Joshua Washington <joshwash@google.com> wrote:

> https://inbox.dpdk.org/dev/20250707231812.1937260-7-joshwash@google.com/
> introduced descriptor limit checks for TSO packets in DPDK.
> Unfortunately, a couple of bugs have been found in the implementation.
> 
> This patch series introduces fixes for those bugs while correcting the
> overly restrictive behavior recently introduced mandating that all
> headers be in the same buffer.
> 
> The final patch in the series introduces tx_pkt_prepare as an option to
> ensure that there is a way to get a clear signal of when packets violate
> hardware limitations. Before a recently introduced patch, the GVE
> behavior was to stop transmitting at the first invalid packet, which
> would allow the application to do any necessary linearization or packet
> modification before attempting to transmit again. It turns out that that
> behavior is considered incorrect, so offer tx_pkt_prepare as an
> alternative.
> 
> Depends-on: series-39707 ("net/gve: fix DQO Tx queue stalls")

You dont need Fixes for anything that changed during 26.11 development
window. Only for changes that need backports.

AI review also mentioned.

Review: [PATCH v2 0/4] net/gve: DQO TSO validation fixes

Applied to next-net (339c992f25) with no conflicts. Each commit
builds with -Dwerror=true.

Patches 1/4 and 4/4 look correct. The seg_offset change in 1/4
matches the descriptor layout: the first seg_remain bytes close out
the open segment, and only the rest is divided by tso_segsz.


Patch 2/4: net/gve: account for multi-mbuf headers when validating TSO

Warning: stale comment in gve_tx_validate_pkt_limits().

The data_len < headlen check is gone, but the comment above it
still says the headers must be "contained in the first segment".
Update it:

	/* TSO headers may span up to GVE_TX_MAX_HEADER_DESCS_TSO
	 * buffers; the payload must not be empty.
	 */


Patch 3/4: net/gve: introduce Tx packet preparation for DQO format

Warning: tx_prepare rejects every TSO packet whose headers span
mbufs, which makes the relaxation in 2/4 unreachable for apps that
call rte_eth_tx_prepare().

GVE_TX_CKSUM_OFFLOAD_MASK_DQO includes RTE_MBUF_F_TX_TCP_SEG through
GVE_TX_CKSUM_OFFLOAD_MASK, so "csum && tso" is just "tso". Every TSO
packet therefore goes through rte_net_intel_cksum_prepare(), and
that returns -ENOTSUP when

	rte_pktmbuf_data_len(m) < l2_len + l3_len + l4_len

The commit message says "in this case" as if some TSO packets skip
the call. None do. Pick one of these:

 - State it plainly: TSO packets that go through tx_prepare must
   have all headers in the first segment. Split headers are only
   accepted from apps that call tx_burst directly. Then drop the
   dead csum variable:

	if (tso) {
		err = rte_net_intel_cksum_prepare(tx_pkt);
		if (err != 0) {
			rte_errno = -err;
			return i;
		}
	}

 - Or seed the pseudo-header for split headers too: read the
   L3/L4 headers with rte_pktmbuf_read() and write the TCP checksum
   field into whichever segment holds it.

Info: this adds a tx_pkt_prepare op and tags it Cc: stable. That is
a new driver op, not a bug fix. Stable maintainers may want it
dropped from the backport, or want the commit message to say why
existing apps need it.