From: Joshua Washington <joshwash@google.com>
To: Jeroen de Borst <jeroendb@google.com>,
Joshua Washington <joshwash@google.com>,
Varun Lakkur Ambaji Rao <varun.la@gmail.com>,
Tathagat Priyadarshi <tathagat.dpdk@gmail.com>,
Rushil Gupta <rushilg@google.com>
Cc: dev@dpdk.org, stable@dpdk.org, Ankit Garg <nktgrg@google.com>
Subject: [PATCH 6/7] net/gve: fix DQO TSO descriptor limit
Date: Mon, 7 Jul 2025 16:18:10 -0700 [thread overview]
Message-ID: <20250707231812.1937260-7-joshwash@google.com> (raw)
In-Reply-To: <20250707231812.1937260-1-joshwash@google.com>
The DQ queue format expects that any MTU-sized packet or segment will
only cross at most 10 data descriptors.
In the non-TSO case, this means that a given packet simply can have at
most 10 descriptors.
In the TSO case, things are a bit more complex. For large TSO packets,
mbufs must be parsed and split into tso_segsz-sized (MSS) segments. For
any such MSS segment, the number of descriptors that would be used to
transmit the segment must be counted. The following restrictions apply
when counting descriptors:
1) Every TSO segment (including the very first) will be prepended by a
_separate_ data descriptor holding only header data,
2) The hardware can send at most up to 16K bytes in a single data
descriptor, and
3) The start of every mbuf counts as a separator between data
descriptors -- data is not assumed to be coalesced or copied
The value of nb_mtu_seg_max is set to GVE_TX_MAX_DATA_DESCS-1 to ensure
that the hidden extra prepended descriptor added to the beginning of
each segment in the TSO case is accounted for.
Fixes: 403c671a46b6 ("net/gve: support TSO in DQO RDA")
Cc: tathagat.dpdk@gmail.com
Cc: stable@dpdk.org
Signed-off-by: Joshua Washington <joshwash@google.com>
Reviewed-by: Ankit Garg <nktgrg@google.com>
---
drivers/net/gve/gve_ethdev.c | 2 +-
drivers/net/gve/gve_tx_dqo.c | 64 +++++++++++++++++++++++++++++++++++-
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index 81325ba98c..ef1c543aac 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -603,7 +603,7 @@ gve_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
.nb_max = priv->max_tx_desc_cnt,
.nb_min = priv->min_tx_desc_cnt,
.nb_align = 1,
- .nb_mtu_seg_max = GVE_TX_MAX_DATA_DESCS,
+ .nb_mtu_seg_max = GVE_TX_MAX_DATA_DESCS - 1,
};
dev_info->flow_type_rss_offloads = GVE_RTE_RSS_OFFLOAD_ALL;
diff --git a/drivers/net/gve/gve_tx_dqo.c b/drivers/net/gve/gve_tx_dqo.c
index 27f98cdeb3..3befbbcacb 100644
--- a/drivers/net/gve/gve_tx_dqo.c
+++ b/drivers/net/gve/gve_tx_dqo.c
@@ -80,6 +80,68 @@ gve_tx_clean_descs_dqo(struct gve_tx_queue *txq, uint16_t nb_descs) {
gve_tx_clean_dqo(txq);
}
+/* GVE expects at most 10 data descriptors per mtu-sized segment. Beyond this,
+ * the hardware will assume the driver is malicious and stop transmitting
+ * packets altogether. Validate that a packet can be sent to avoid sending
+ * posting descriptors for an invalid packet.
+ */
+static inline bool
+gve_tx_validate_descs(struct rte_mbuf *tx_pkt, uint16_t nb_descs, bool is_tso)
+{
+ if (!is_tso)
+ return nb_descs <= GVE_TX_MAX_DATA_DESCS;
+
+ int tso_segsz = tx_pkt->tso_segsz;
+ int num_descs, seg_offset, mbuf_len;
+ int headlen = tx_pkt->l2_len + tx_pkt->l3_len + tx_pkt->l4_len;
+
+ /* Headers will be split into their own buffer. */
+ num_descs = 1;
+ seg_offset = 0;
+ mbuf_len = tx_pkt->data_len - headlen;
+
+ while (tx_pkt) {
+ if (!mbuf_len)
+ goto next_mbuf;
+
+ int seg_remain = tso_segsz - seg_offset;
+ if (num_descs == GVE_TX_MAX_DATA_DESCS && seg_remain)
+ return false;
+
+ if (seg_remain < mbuf_len) {
+ seg_offset = mbuf_len % 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
+ * is not at risk of defying this limitation.
+ * Thus, such segments are ignored.
+ */
+ int mbuf_remain = tx_pkt->data_len % GVE_TX_MAX_BUF_SIZE_DQO;
+
+ /* For each TSO segment, HW will prepend
+ * headers. The remaining bytes of this mbuf
+ * will be the start of the payload of the next
+ * TSO segment. In addition, if the final
+ * segment in this mbuf is divided between two
+ * descriptors, both must be counted.
+ */
+ num_descs = 1 + !!(seg_offset) +
+ (mbuf_remain < seg_offset && mbuf_remain);
+ } else {
+ seg_offset += mbuf_len;
+ num_descs++;
+ }
+
+next_mbuf:
+ tx_pkt = tx_pkt->next;
+ if (tx_pkt)
+ mbuf_len = tx_pkt->data_len;
+ }
+
+
+ return true;
+}
+
static uint16_t
gve_tx_pkt_nb_data_descs(struct rte_mbuf *tx_pkt)
{
@@ -166,7 +228,7 @@ gve_tx_burst_dqo(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
}
/* Drop packet if it doesn't adhere to hardware limits. */
- if (!tso && nb_descs > GVE_TX_MAX_DATA_DESCS) {
+ if (!gve_tx_validate_descs(tx_pkt, nb_descs, tso)) {
txq->stats.too_many_descs++;
break;
}
--
2.50.0.727.gbf7dc18ff4-goog
next prev parent reply other threads:[~2025-07-07 23:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 23:18 [PATCH 0/7] net/gve: Tx datapath fixes for GVE DQO Joshua Washington
2025-07-07 23:18 ` [PATCH 1/7] net/gve: send whole packet when mbuf is large Joshua Washington
2025-07-07 23:18 ` [PATCH 2/7] net/gve: clean when there are insufficient Tx descs Joshua Washington
2025-07-07 23:18 ` [PATCH 3/7] net/gve: don't write zero-length descriptors Joshua Washington
2025-07-07 23:18 ` [PATCH 4/7] net/gve: validate Tx packet before sending Joshua Washington
2025-07-07 23:18 ` [PATCH 5/7] net/gve: add DQO Tx descriptor limit Joshua Washington
2025-07-07 23:18 ` Joshua Washington [this message]
2025-07-07 23:18 ` [PATCH 7/7] net/gve: clear DQO Tx descriptors before writing 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=20250707231812.1937260-7-joshwash@google.com \
--to=joshwash@google.com \
--cc=dev@dpdk.org \
--cc=jeroendb@google.com \
--cc=nktgrg@google.com \
--cc=rushilg@google.com \
--cc=stable@dpdk.org \
--cc=tathagat.dpdk@gmail.com \
--cc=varun.la@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).