[PATCH net-next v5] net: airoha: add HW GRO offload support

[Paolo Abeni]

On 8/31/26 8:34 AM, Lorenzo Bianconi wrote:
> Add hardware GRO offload support to the airoha_eth driver, leveraging
> the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues mapped to RX
> queues 24-31. HW GRO offloading does not support Scatter-Gather (SG) so
> it is required to increase the page_pool allocation order to 2 for RX
> queues 24-31 (LRO queues).
> Since HW GRO is configured per-QDMA and shared across all devices using
> it, HW GRO is mutually exclusive with multiple devices bound to the
> same QDMA block. Call airoha_update_netdev_features() in
> airoha_dev_set_qdma() so that NETIF_F_GRO_HW availability is re-evaluated
> whenever the QDMA user count changes (device registration and runtime QDMA
> migration).
> Set CHECKSUM_PARTIAL with pseudo-header checksum on aggregated packets
> so that L3-forwarded traffic is correctly handled by the GSO/TSO path
> on the egress device.
> The HW does not report the per-segment MSS (msg3[31:16] only reports
> the max aggregated size), so the gso_size of an aggregated packet is
> just an approximation computed as DIV_ROUND_UP(data_len, agg_count).

What is the <max aggregated size> exactly? I read it as the maximum size
of the aggregated segments, am I correct?

Also any more details on how the aggregation engine works? i.e. can it
aggregate "random" segment sizes (i.e. 200 - 300 - 400) or does it
respect HW_GRO layout? (i.e. all segments except the last one must have
equal size, the can be smaller).

In the 'good' scenario, than by definition gso_size == <max aggregated
size> - <total hdr len>, and you are better off computing the gso_size
from <max aggregated size>.

Otherwise I think we can't call this HW_GRO - even if it would be more
convenient for the driver.

/P