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

[Lorenzo Bianconi]

> 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?

Hi Paolo,

with "max aggregated size" I refer to the length of the aggregated TCP
packet (composed by multiple segments). This value is reported via
QDMA_DESC_LEN_MASK field in the DMA descriptor. Moreover, the hw reports
the exact number of the aggregated segments via QDMA_ETH_RXMSG_AGG_COUNT_MASK
field.

> 
> 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).

The hw engine, for each LRO queue, is configured with:

- CDM_LRO_AGG_NUM_MASK: max number of segments for each aggregated TCP packet
                        (64 in the current configuration).
- CDM_LRO_AGG_SIZE_MASK: max size of the aggregated TCP packet (composed by
                         multiple segments). 16KB in the current configuration.
- CDM_LRO_AGG_TIME_MASK: max timeout to compose the aggregated TCP packet.

In order to validate the scenario, I run the following test:

TCP client:
------------
- disable TSO/GSO
- set MSS to 256 bytes (iperf3 -M option)

I can see multiple 310 bytes TCP segments on the wire

TCP server: (where rx-gro-hw is enabled):
-------------------------------------------
- the engine aggregates ~64 segments in a ~16Kbyes TCP packet

  so gso_size ~ 16KB / 64 ~ 256B

I guess this would be the behaviour even if the original packets
have different size (not sure if it is a real use-case).

Regards,
Lorenzo

> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260903/bc340eae/attachment.sig>