On Tue, 19 Sep 2006 16:26:12 -0700 Auke Kok <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote: > > On Tue, 19 Sep 2006 16:45:06 -0400 > > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >> looks OK except for the tasklet, which may starve if the lock is being > >> held upon entry > >> > >> > > > > Why would the tasklet starve anymore than NAPI? > > Worst case, the transmitters fill the ring completely and have to > > wait for the tasklet to clean up. > > > > Maybe it would be better to always to Tx cleanup in tasklet even with > > NAPI. Then the NAPI poll flow control would be used only for Rx. > > As it stands, if receiver gets swamped, the poll doesn't get run often, > > so the transmitter cleanup doesn't get run. A tasklet has the advantage > > of eliminating the need for adapter->tx_queue_lock as well. > > I gave it a spin and it looks horrible with NAPI - the box almost freezes up > with even 2 clients. Minor nitpick: you forgot to delete a > spin_lock_irqsave() > call but gcc would have spotted that for you. Unsurprisingly it's more stable > without NAPI. > > I'm unsure (not enough knowlege) why you would prefer to remove lltx - care > to > enlighten me? It is just that bouncing in and out of the driver to do spin lock attempts is awkward. I don't think the implementation of LLTX was meant for devices that lock, more for software devices like loopback. The patch was more of an experiment to see if there was a simpler way. - 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
