Re: [PATCH net-next] net: airoha: Add TCP LRO support

On Tue, 10 Jun 2025 15:39:34 +0200 Lorenzo Bianconi wrote:

quoted

quoted

Tell us more... It seems small LRO packets will consume a lot of
space, incurring a small skb->len/skb->truesize ratio, and bad TCP WAN
performance.  

I think the main idea is forward to hw LRO queues (queues 24-31 in this
case) just specific protocols with mostly big packets but I completely
agree we have an issue for small packets. One possible approach would be
to define a threshold (e.g. 256B) and allocate a buffer or page from the
page allocator for small packets (something similar to what mt7601u driver
is doing[0]).  What do you think?

I'm not Eric but FWIW 256B is not going to help much. It's best to keep
the len / truesize ratio above 50%, so with 32k buffers we're talking
about copying multiple frames.

Hi Jakub,

what I mean here is reallocate the skb if the true size is small (e.g. below
256B) in order to avoid consuming the high order page from the page_pool. Maybe
we can avoid it if reducing the page order to 2 for LRO queues provide
comparable results.

quoted

quoted

And order-5 pages are unlikely to be available in the long run anyway.  

I agree. I guess we can reduce the order to ~ 2 (something similar to
mtk_eth_soc hw LRO implementation [1]).

Would be good to test. SW GRO can "re-GRO" the partially coalesced
packets, so it's going to be diminishing returns.

ack, I will do.

quoted

quoted

LRO support would only make sense if the NIC is able to use multiple
order-0 pages to store the payload.  

The hw supports splitting big packets over multiple order-0 pages if we
increase the MTU over one page size, but according to my understanding
hw LRO requires contiguous memory to work.

Hm, you're already passing buffers smaller than normal TSO so
presumably having a smaller buffers will break the sessions more 
often but still work?

I will test it.

You mean want to steal some of the code from:
https://lore.kernel.org/all/20250421222827.283737-1-kuba@kernel.org/ (local)

ack, I will take a look.

and make the buffer size user-configurable. But not a requirement.
Let's at least get some understanding of the perf benefit of 
32k vs 16k or 8k

ack, I will do.

Regards,
Lorenzo

-- 
pw-bot: cr