On Sun, Nov 1, 2026 at 11:46 PM Stephen Hemminger
<[email protected]> wrote:
>
> 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.
Which patch(es) does this refer to? I think some of these patches are
fixing previous fixes. For those patches, should I just base the fix
on the same patch that the original fix was addressing? Otherwise,
they could be applied to next-net, but not as fixes, which would
prevent backporting.
>
> 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.
I will drop patch 2, since the driver requires checksum offloading for
TSO packets.
>
> 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.
--
Joshua Washington | Software Engineer | [email protected] | (414) 366-4423
