Re: [PATCH v2 0/2] net/gve: Rx scatter for GQI

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 19 Oct 2026 16:20:02 -0400
Ryan Wolfe <rnwolfe@google.com> wrote:

> GQI receives a frame larger than one Rx buffer as a chain of mbufs, but
> the driver doesn't report RTE_ETH_RX_OFFLOAD_SCATTER, and it chains
> whether or not the application enabled it. 1/2 reports SCATTER for GQI
> so an application that gates multi-segment receive on the capability,
> such as VPP, can turn it on. 2/2 refuses an Rx queue setup or an MTU
> change that would need scatter when the application hasn't enabled it.
> 
> Both patches change only the GQI queue format. DQO has a related
> problem that this series leaves alone: its Rx path ignores
> end_of_packet, so with Rx buffers smaller than the frame each buffer
> is delivered as its own packet. DQO should either chain those buffers
> or refuse that configuration too; that is left for a follow-up.
> 
> One more gap 2/2 doesn't close: the check reads dev->data->mtu, but gve
> never pushes that value to the device. rte_eth_dev_configure() sets it
> without calling mtu_set, so an application that never calls
> rte_eth_dev_set_mtu() passes the check at 1500 while the device keeps
> the MTU from its device descriptor, and on a jumbo VPC it can still get
> chained frames. Applying dev->data->mtu at configure or start would fix
> that but changes behavior and needs hardware to test, so it is left for
> the same follow-up.
> 
> v2:
> - add 2/2 to refuse MTUs that need scatter when it isn't enabled
>   (Stephen)
> - correct the DQO statement in 1/2

Applied to next-net

AI review had a followup suggestion:

Subject: Re: [PATCH v2 0/2] net/gve: Rx scatter for GQI

Applies to main; both commits build with -Dwerror=true.

Info

[PATCH v2 2/2] net/gve: refuse an MTU that needs Rx scatter when it
is off

1. rte_eth_dev_configure() sets dev->data->mtu directly from
   rxmode.mtu without calling mtu_set, and keeps already set up Rx
   queues when the queue count is unchanged. So stop, reconfigure with
   a larger MTU (or without SCATTER), and start without redoing queue
   setup passes both checks. Moving the mtu_set loop into a helper and
   calling it from gve_dev_start() as well covers that path:

       static int
       gve_rx_check_scatter(struct rte_eth_dev *dev, uint16_t mtu)
       {
               struct gve_priv *priv = dev->data->dev_private;
               uint16_t i;

               if (!gve_is_gqi(priv) ||
                   (dev->data->dev_conf.rxmode.offloads &
                    RTE_ETH_RX_OFFLOAD_SCATTER))
                       return 0;

               for (i = 0; i < dev->data->nb_rx_queues; i++) {
                       struct gve_rx_queue *q = dev->data->rx_queues[i];

                       if (q != NULL &&
                           gve_rx_gqi_needs_scatter(mtu, q->rx_buf_len)) {
                               PMD_DRV_LOG(ERR,
                                       "MTU %u needs Rx scatter", mtu);
                               return -EINVAL;
                       }
               }
               return 0;
       }

   Not required for this series; can be a follow up.