Initial testing shows that for 64 simulaneous TCP connections on the same RX ring utilizing 100% CPU in both testcases, the throughput roughly doubles:

Before RSS LRO: 4-5GBit/s
With MLX5EN modified to use RSS LRO: 10.4 GBit/s

Tested using iperf on a 100GBit/s link.

Look good to me. It also refactors out most commonly used lro_flush pattern in many drivers, i.e. when rx_pkts > rx_pkts_max, flush all active LRO entries.

@rrs Do you have suggestions for better function names?

BTW: I think this patch has a positive effect on the CPU cache utilization. The PCBGROUP feature selects bucket based on the flowid, and when mbufs are sorted according to the flowids, the likelyhood of the next bucket selected already being in the CPU cache increases. Further if the PCBGROUP code sorted the entries in the the lists by "flowid", the lookup time can be reduced further, at best into a single-pass for the LISTS's involved, iff the last looked up entry can be cached/stored somehow ...

General comments:

• First, this is an awesome idea. In practice, with machines with tens of thousands of connections, this increases our aggregation rate from ~1.3:1 to almost 3:1. Just fantastic. Thanks for thinking out of the box!

• Naming: I understand why you named things the way you did (tcp_lro_rss_flush, tcp_lro_rss_rx), but perhaps the code would be a bit more understandable with different names. The names caused me substantial confusion, and also caused confusion when I was walking another person through this review. I think avoiding duplicating the _rx and _flush names would be helpful to eliminate confusion between the new functions, and the old ones that the wrap. Perhaps tcp_lro_rss_rx() could be something like tcp_lro_store_mb() ? And tcp_lro_rss_flush could be something like tcp_lro_rss_submit()?

• It would be interesting to see stats on RSS hash collisions (eg, the max number of active aggregations). It may be that we could reduce the number of LRO aggregations down to 2. One that is almost always used, and one for the rare case of a collision.

I'll wait and see a bit if there are more comments popping in and then generate a new patch with updated function names:

tcp_lro_rss_rx -> tcp_lro_put_mbuf
tcp_lro_rss_init -> tcp_lro_init_mbuf
tcp_lro_rss_flush -> tcp_lro_flush_mbufs
tcp_lro_rss_free -> tcp_lro_free (merge into one function only)