Re: [PATCH] net/gve: check the Rx scatter MTU at device start

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 21 Oct 2026 14:25:22 -0400
Ryan Wolfe <rnwolfe@google.com> wrote:

> rte_eth_dev_configure() sets the MTU from rxmode.mtu without calling
> mtu_set, and keeps Rx queues that are already set up when the queue
> count doesn't change. Stopping the port and reconfiguring it with a
> larger MTU, or without RTE_ETH_RX_OFFLOAD_SCATTER, therefore skipped
> both the MTU change check and the Rx queue setup check, and GQI went
> on to chain large frames for an application that hadn't enabled
> scatter.
> 
> Move the check into gve_rx_check_scatter() and call it from
> gve_dev_start() as well as gve_dev_mtu_set(), so starting such a
> configuration fails with an error log instead.
> 
> Fixes: cffdca824388 ("net/gve: refuse an MTU that needs Rx scatter when it is off")
> Cc: stable@dpdk.org
> 
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ryan Wolfe <rnwolfe@google.com>
> ---

AI found a flaw in this logic

Review: [PATCH] net/gve: check the Rx scatter MTU at device start
Patchwork: 171827

Applied on top of cffdca824388 (next-net-for-main); builds clean with
-Dwerror=true for net/gve.

Warning

gve_dev_start() checks dev->data->mtu, but gve never gives that MTU to
the device. The only caller of ctrl_ops->set_mtu() is gve_dev_mtu_set(),
and rte_eth_dev_configure() just assigns dev->data->mtu from
rxmode.mtu. After configure the gVNIC keeps whatever MTU it had (its
default, or the last mtu_set), so the start check validates a number
the hardware is not using. With rxmode.mtu left at 0 (1500) on a
device running a larger MTU, the check passes and GQI still chains
frames up to the device MTU without scatter.

Program the MTU at start, after the check, so the two agree:

	ret = gve_rx_check_scatter(dev, dev->data->mtu);
	if (ret != 0)
		return ret;

	ret = process_priv->ctrl_ops->set_mtu(priv, dev->data->mtu);
	if (ret != 0) {
		PMD_DRV_LOG(ERR, "Failed to set MTU %u: %d",
			    dev->data->mtu, ret);
		return ret;
	}

(move "priv = dev->data->dev_private;" to the top of the function.)
This also fixes rxmode.mtu being ignored by gve, which is the larger
bug here.

"Not yet run on gVNIC". Please test on GQI before v2: testpmd, port
stop, port config mtu / reconfigure without scatter, port start must
fail; and with the set_mtu change, confirm a 1500 MTU config drops
jumbo frames.

Info

Commit message: ethdev keeps already set up Rx queues below the new
count whether or not the count changes (eth_dev_rx_queue_config only
releases queues >= nb_queues). Drop "when the queue count doesn't
change".

cffdca824388 is only in next-net-for-main, not in any release. This
can be squashed into it when merging; if kept separate, Cc: stable is
not needed since the Fixes target already carries it.