On Wed, 21 Oct 2026 14:25:22 -0400
Ryan Wolfe <[email protected]> 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: [email protected]
>
> Reported-by: Stephen Hemminger <[email protected]>
> Signed-off-by: Ryan Wolfe <[email protected]>
> ---
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.
