From: Joshua Washington <joshwash@google.com>
To: Joshua Washington <joshwash@google.com>, Ankit Garg <nktgrg@google.com>
Cc: dev@dpdk.org, stable@dpdk.org,
Praveen Kaligineedi <pkaligineedi@google.com>
Subject: [PATCH 1/3] net/gve: fix segment TSO segment offset calculation
Date: Mon, 26 Oct 2026 13:23:25 -0700 [thread overview]
Message-ID: <20261026202327.3897802-2-joshwash@google.com> (raw)
In-Reply-To: <20261026202327.3897802-1-joshwash@google.com>
The descriptor limit validation for TSO packets was erroneously
computing the TSO segment offset at the end of an mbuf. The first bytes
of any mbuf will be included as part of the previous TSO segment which
has not yet been completed, as indicated by seg_remain. Subtract those
seg_remain bytes from the mbuf length before computing the segment
offset.
Visual representation:
Before:
------------------------------------------------------------------
| tso_ | tso_ | tso_ | tso_ | tso_ |
| segsz | segsz | segsz | segsz | segsz |
------------------------------------------------------------------
| 16K | 16K | |
------------------------------------------------------------------
After:
------------------------------------------------------------------
|rem | tso_ | tso_ | tso_ | tso_ | seg_ |
|ain | segsz | segsz | segsz | segsz |offset |
------------------------------------------------------------------
| 16K | 16K | |
------------------------------------------------------------------
^
mbuf_remain
In this example, the original code would have found that tso_segsz
evenly divides mbuf_len, and that there is no tail to be considered
split across two mbufs. So the number of descriptors it would have found
would be:
1 (for the headers) +
0 (no segment offset) +
0 (mbuf_remain cannot be less than 0)
For a total of one descriptor counted in num_descs for the start of
the current TSO segment.
Meanwhile, the reality would be:
1 (for the headers) +
1 (seg_offset != 0) +
1 (mbuf_remain < seg_offset)
For a total of 3 descriptors counted against the descriptor limit.
This undercount can cause TSO segments to incorrectly cross up to two
extra descriptors more than the hardware limit, leading to the datapath
being disabled.
Fixes: be8f0eb81f98 ("net/gve: fix DQO TSO descriptor limit")
Cc: stable@dpdk.org
Signed-off-by: Joshua Washington <joshwash@google.com>
Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
Reviewed-by: Ankit Garg <nktgrg@google.com>
---
Depends-on: series-39707 ("net/gve: fix DQO Tx queue stalls")
---
drivers/net/gve/gve_tx_dqo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gve/gve_tx_dqo.c b/drivers/net/gve/gve_tx_dqo.c
index 52fcdb285a..3a20109a5d 100644
--- a/drivers/net/gve/gve_tx_dqo.c
+++ b/drivers/net/gve/gve_tx_dqo.c
@@ -191,7 +191,7 @@ gve_tx_validate_descs(const struct gve_tx_queue *txq, struct rte_mbuf *tx_pkt,
return false;
if (seg_remain < mbuf_len) {
- seg_offset = mbuf_len % tso_segsz;
+ seg_offset = (mbuf_len - seg_remain) % tso_segsz;
/* The MSS is bound from above by 9728B, so a
* single TSO segment in the middle of an mbuf
* will be part of at most two descriptors, and
--
2.56.0.307.g5fe7bd680c-goog
next prev parent reply other threads:[~2026-10-26 20:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 20:23 [PATCH 0/3] net/gve: TSO descriptor count fixes for GVE DQO Joshua Washington
2026-10-26 20:23 ` Joshua Washington [this message]
2026-10-26 20:23 ` [PATCH 2/3] net/gve: account for multi-mbuf headers when validating TSO Joshua Washington
2026-10-26 20:23 ` [PATCH 3/3] net/gve: introduce Tx packet preparation for DQO format Joshua Washington
2026-10-27 4:14 ` [PATCH 0/3] net/gve: TSO descriptor count fixes for GVE DQO Stephen Hemminger
2026-10-30 0:18 ` Joshua Washington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261026202327.3897802-2-joshwash@google.com \
--to=joshwash@google.com \
--cc=dev@dpdk.org \
--cc=nktgrg@google.com \
--cc=pkaligineedi@google.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox