[PATCH] net/gve: advertise Rx scatter in GQI queue format

[PATCH] net/gve: advertise Rx scatter in GQI queue format

[Ryan Wolfe]

Since jumbo frame support for GQI, a frame that does not fit in one Rx
buffer arrives as several descriptors with GVE_RXF_PKT_CONT set on all
but the last, and gve_rx_burst() chains them into one multi-segment
mbuf. The driver never reports RTE_ETH_RX_OFFLOAD_SCATTER, though, so
an application that enables multi-segment receive only when the port
claims it treats every packet as one segment. VPP is one: it masks its
requested Rx offloads with rx_offload_capa, so on a GQI gVNIC it never
sets its multi-segment flag, reads only the first buffer of a jumbo
frame and drops it as malformed. With 4 KB buffers that caps the usable
MTU near 4000 bytes on a VPC whose MTU is 8896.

Report SCATTER for GQI. DQO posts one buffer per packet and does not
chain, so it is unchanged.

Fixes: 496d4d2c8b54 ("net/gve: support jumbo frame for GQI")
Cc: stable@dpdk.org

Signed-off-by: Ryan Wolfe <rnwolfe@google.com>
---
 .mailmap                         | 1 +
 doc/guides/nics/features/gve.ini | 1 +
 drivers/net/gve/gve_ethdev.c     | 5 +++++
 3 files changed, 7 insertions(+)

diff --git a/.mailmap b/.mailmap
index 6d9e262cfb..87c544947c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1477,6 +1477,7 @@ Ruifeng Wang <ruifeng.wang@arm.com>
 Rupesh Chiluka <rchiluka@marvell.com>
 Rushil Gupta <rushilg@google.com>
 Ryan E Hall <ryan.e.hall@intel.com>
+Ryan Wolfe <rnwolfe@google.com>
 Sabyasachi Sengupta <sabyasg@hpe.com>
 Sachin Saxena <sachin.saxena@nxp.com> <sachin.saxena@oss.nxp.com>
 Sagar Abhang <sabhang@brocade.com>
diff --git a/doc/guides/nics/features/gve.ini b/doc/guides/nics/features/gve.ini
index 9f3835edf6..5566511b6b 100644
--- a/doc/guides/nics/features/gve.ini
+++ b/doc/guides/nics/features/gve.ini
@@ -7,6 +7,7 @@
 Speed capabilities   = Y
 Queue start/stop     = Y
 MTU update           = Y
+Scattered Rx         = P
 TSO                  = Y
 RSS hash             = Y
 RSS key update       = Y
diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index 3c8d1a76e4..92a5a7679f 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -897,6 +897,11 @@ gve_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 	dev_info->min_mtu = RTE_ETHER_MIN_MTU;
 
 	dev_info->rx_offload_capa = RTE_ETH_RX_OFFLOAD_RSS_HASH;
+	/* GQI receives a frame larger than one Rx buffer as a chain of
+	 * buffers (gve_rx_burst follows GVE_RXF_PKT_CONT).
+	 */
+	if (gve_is_gqi(priv))
+		dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_SCATTER;
 	if (priv->clk_read_type != GVE_DEV_CLK_UNSUPPORTED &&
 	    priv->nic_ts_report_mz != NULL)
 		dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_TIMESTAMP;

Re: [PATCH] net/gve: advertise Rx scatter in GQI queue format

[Stephen Hemminger]

On Sun, 18 Oct 2026 22:28:24 -0400
Ryan Wolfe <rnwolfe@google.com> wrote:

> Since jumbo frame support for GQI, a frame that does not fit in one Rx
> buffer arrives as several descriptors with GVE_RXF_PKT_CONT set on all
> but the last, and gve_rx_burst() chains them into one multi-segment
> mbuf. The driver never reports RTE_ETH_RX_OFFLOAD_SCATTER, though, so
> an application that enables multi-segment receive only when the port
> claims it treats every packet as one segment. VPP is one: it masks its
> requested Rx offloads with rx_offload_capa, so on a GQI gVNIC it never
> sets its multi-segment flag, reads only the first buffer of a jumbo
> frame and drops it as malformed. With 4 KB buffers that caps the usable
> MTU near 4000 bytes on a VPC whose MTU is 8896.
> 
> Report SCATTER for GQI. DQO posts one buffer per packet and does not
> chain, so it is unchanged.
> 
> Fixes: 496d4d2c8b54 ("net/gve: support jumbo frame for GQI")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Ryan Wolfe <rnwolfe@google.com>
> ---
Subject: Re: [PATCH] net/gve: advertise Rx scatter in GQI queue format

Applies to main and builds with -Dwerror=true. The Fixes hash
resolves.

Warnings

1. GQI chains buffers whether or not the application enabled scatter.

   With this patch an application can request
   RTE_ETH_RX_OFFLOAD_SCATTER, but gve_rx() follows GVE_RXF_PKT_CONT
   regardless, so one that does not still gets multi-segment mbufs
   whenever the MTU exceeds the Rx buffer. Advertising the capability
   is only half the contract; without SCATTER the driver must refuse
   the configuration rather than hand back chains the application
   did not ask for. Check it in gve_rx_queue_setup() before the rxq
   allocation:

       uint64_t offloads = dev->data->dev_conf.rxmode.offloads |
                           conf->offloads;
       uint32_t buf_len = RTE_MIN((uint32_t)GVE_RX_MAX_BUF_SIZE_GQI,
               RTE_ALIGN_FLOOR(rte_pktmbuf_data_room_size(pool) -
                               RTE_PKTMBUF_HEADROOM,
                               GVE_RX_BUF_ALIGN_GQI));

       if (!(offloads & RTE_ETH_RX_OFFLOAD_SCATTER) &&
           dev->data->mtu + RTE_ETHER_HDR_LEN + GVE_RX_PAD > buf_len) {
               PMD_DRV_LOG(ERR, "MTU %u needs Rx scatter",
                           dev->data->mtu);
               return -EINVAL;
       }

   and apply the same test in gve_dev_mtu_set() against the configured
   Rx queues, since the MTU can change after queue setup. A separate
   patch in the same series is fine.

Info

2. The commit message says DQO "does not chain, so it is unchanged".
   DQO Rx ignores end_of_packet, so with buffers smaller than the
   frame (2 KB mbufs, 8896 MTU) each buffer is delivered as its own
   packet. Not introduced here, but DQO should either chain or refuse
   that configuration too.