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
