On Fri, 30 Oct 2026 11:42:59 -0700 Joshua Washington <[email protected]> wrote:
> https://inbox.dpdk.org/dev/[email protected]/ > 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.
