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

[Ryan Wolfe]

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

Ryan Wolfe (2):
  net/gve: advertise Rx scatter in GQI queue format
  net/gve: refuse an MTU that needs Rx scatter when it is off

 .mailmap                         |  1 +
 doc/guides/nics/features/gve.ini |  1 +
 drivers/net/gve/gve_ethdev.c     | 23 +++++++++++++++++++++++
 drivers/net/gve/gve_ethdev.h     |  9 +++++++++
 drivers/net/gve/gve_rx.c         | 31 +++++++++++++++++++++++++------
 5 files changed, 59 insertions(+), 6 deletions(-)

-- 
2.56.0.218.g1ec904b173-goog