On Tue, Apr 21, 2009 at 03:19:14PM -0400, Andrew Gallatin wrote:
I was sure I had tested my case with the IRQs bound (using a cxgb3),
but when I tried it again today GRO was indeed slower (8G vs. 9.4G)!
I fiddled with it all day and couldn't figure out why this was
so. We weren't spending any more time in the GRO code than LRO,
and in fact we were aggregating more packets with GRO (700k segments
instead of 900k segments). GRO was also sending a lot less ACKs
than LRO.
It finally dawned on me that my sender had been upgraded from 2.6.18
to 2.6.30-rc1. Indeed, rebooting into 2.6.18 seems to restore
the balance between GRO and LRO. I wonder if the ACK reduction
has anything to do with this.
Hopefully tomorrow I'll get my hands onto a myricom and try to
replicate your problem.
In the mean time, can you see if there is any disparity in the
number of aggregated segments and ACKs between GRO and LRO?
netstat -s should be sufficient to measure this (TCP segments
received and sent).
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html