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

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/171732

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-20

# DPDK Patch Review

## ERRORS

None.

## WARNINGS

None.

## INFO

### Patch 1/2: Advertise Rx scatter capability

**Observation**: The patch correctly adds `RTE_ETH_RX_OFFLOAD_SCATTER` to `rx_offload_capa` for GQI mode, matching the existing behavior where `gve_rx_burst()` chains multi-segment mbufs when frames exceed one buffer.

**Documentation**: The `.ini` file uses `P` (partially supported) for the Scattered Rx feature rather than `Y` (fully supported). Given that this patch only enables scatter for GQI and explicitly does not touch DQO (as stated in the commit message), this appears intentional and correct.

### Patch 2/2: MTU validation

**Structure**: The patch introduces a helper `gve_rx_gqi_needs_scatter()` that encapsulates the scatter requirement calculation (frame size > buffer size). This helper is then used in both `gve_rx_queue_setup()` and `gve_dev_mtu_set()` to reject configurations where scatter would be required but is not enabled. The calculation is consistent between the two call sites.

**Overhead calculation**: The code uses `mtu + RTE_ETHER_HDR_LEN + GVE_RX_PAD` to determine the required buffer size. This is frame length (L2 + L3), not just MTU. The pattern is correct for this driver's buffer layout.

**Queue iteration**: In `gve_dev_mtu_set()`, the code iterates over all configured Rx queues checking if any would require scatter with the new MTU. The iteration checks `rxq != NULL` before dereferencing, which is appropriate since `rx_queues[]` may contain NULL entries.

**Error messages**: Both rejection paths provide clear diagnostic output including the MTU value and the Rx buffer length that was insufficient.

Review-Result: CLEAN