net/gve: Rx scatter for GQI

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