Eli Cohen wrote:
the 64K comes from the fact that an IP datagram's max length is 64K. And since LRO involves generating at the receiver a hand made IP datagram, the max length is 64K.
The .max_aggr field comes to say "Max number of LRO packets to be
aggregated" and not "max number of k bytes to aggregate. As you say, the
packets are aggregated into a legal IP packet which is pushed up to the
stack, whose size can not exceed 64k and as such the __lro_proc_skb code
at net/ipv4/inet_lro.c does
if ((lro_desc->pkt_aggr_cnt >= lro_mgr->max_aggr) ||
lro_desc->parent->len > (0xFFFF - lro_mgr->dev->mtu))
lro_flush(lro_mgr, lro_desc);
so in the case of a 64K message sent over 2044 mtu, .max_aggr of 32 or
33 would serve well as large-receive-offload which is a software-based
mirror mechanism for LSO.
For the case of small --messages-- eg of 1K, I don't see why we want to
aggregate more then 32 of them, is it just because this code appears in
other drivers?
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
