On Wed, 2005-07-12 at 00:18 -0800, Jesse Brandeburg wrote: > On 12/6/05, Robert Olsson <[EMAIL PROTECTED]> wrote: > > jamal writes: > > > > > Results: > > > -------- > > > > > > kernel 2.6.11.7: 446Kpps > > > kernel 2.6.14: 452kpps > > > kernel 2.6.14 with e1000-6.2.15: 470Kpps > > > Kernel 2.6.14 with e1000-6.2.15 but rx copybreak commented out: 460Kpps > > > > copybreaks help you.. > > Thanks for running these tests, so far it mostly validates that for > the general case the copybreak and prefetch benefits things.
I dont know what you would call a general case. Pick two modern boards as in these tests: a) An Opteron showing copybreak is a bad thing. That some prefetch is good. b) a dual xeon/hyperthreading showing it may be a good thing to have copybreak. I need to complete the tests with xeon, but the above with copybreak looks tantalizing. My concerns were not with these sorts of boards used actually - rather a 3 year old piece of hardware and yet we are seeing contradictory results with these two. Too bad i dont have slightly older functional hardware because i believe it would have even been more interesting. > > > Also - to the intel folks, any reason this behavior was made default? > > Flow control is generally a good thing unless you absolutely don't > want to tell the switch to pause. The default is configured in the > eeprom, and the driver has parameters and ethtool config for those > (like you) who need to turn it off. For the general case of a server > or a client NIC I believe Flow control to be good. I won't argue that > sometimes it makes performance non-deterministic however. It is possible it will help some traffic setups to turn it on, however, forever you had it as off. So people who need it know how to turn it on. The sudden change of behavior that was questionable and btw it is not documented either. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html