On Wed, Jun 03, 2009 at 12:47:04PM +0930, Rusty Russell wrote: > > We could figure out if we can take the worst-case packet, and underutilize > our queue. And fix the other *67* drivers. Most of those are for debugging purposes, i.e., they'll never happen unless the driver is buggy. > Of course that doesn't even work, because we return NETDEV_TX_BUSY from dev.c! If and when your driver becomes part of the core and it has to feed into other drivers, then you can use this argument :) > "Hi, core netdevs here. Don't use NETDEV_TX_BUSY. Yeah, we can't figure out > how to avoid it either. But y'know, just hack something together". No you've misunderstood my complaint. I'm not trying to get you to replace NETDEV_TX_BUSY by the equally abhorrent queue in the driver, I'm saying that you should stop the queue before you get a packet that overflows by looking at the amount of free queue space after transmitting each packet. For most drivers this is easy to do. What's so different about virtio-net that makes this impossible? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization