On Thursday 02 February 2006 08:31, Greg Banks wrote: > The tg3 driver uses small hardcoded values for the RXCOL_TICKS > and RXMAX_FRAMES registers, and allows "ethtool -C" to change > them. SGI's solution is do is ship a script that uses ethtool > at boot to tune rx-usecs, rx-frames, rx-usecs-irq, rx-frames-irq > up from the defaults.
All user tuning like this is bad. The stack should all do that automatically. Would there be a drawback of making these settings default? > This helps a lot, and we're very grateful ;-) But a scheme > which used the interrupt mitigation hardware dynamically based on > load could reduce the irq rate and CPU usage even further without > compromising latency at low load. If you know what's needed perhaps you could investigate it? > Sure, except that the last time SGI looked at TSO it was > extremely flaky. I believe David has done quite a lot of work on it and it should be much better much. > I gather that's much better now, but TSO > still has a very small size limit imposed by the stack (not > the hardware). You mean the 64k limit? > > > I was playing with a design some time ago to let TCP batch > > the lower level transactions even without that. The idea > > was instead of calling down into IP and dev_queue_xmit et.al. > > for each packet generated by TCP first generate a list of packets > > in sendmsg/sendpage and then just hand down the list > > through all layers into the driver. > > Cool. Wouldn't it mean rewriting the nontrivial qdiscs? It had some compat code that just split up the lists - same for netfilter. And only an implementation for pfifo_fast. (Don't ask for code - it's not really in an usable state) -Andi - 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
