From: Rusty Russell <rusty@xxxxxxxxxxxxxxx> Date: Fri, 16 May 2008 12:01:48 +1000 > Dave, please allow me to ask a heretical question. Returning > TX_BUSY has some appeal for virtio_net: is it fundamentally a flawed > idea, or simply a matter of coding? Allowing TX_BUSY adds a special case to the caller which we'd like to remove at some point. > Currently we have no virtio interface to ask how many descriptors are left; > it's not clear that it's a fair question to ask, since for Xen it's depends > on the actual buffers we're trying to put in the descirptors. Two things: 1) You can always make sure that you have enough space for a TSO frame, with arbitrary page boundaries and thus buffer chopping. It can even be estimated, and if violated by some corner case you can punt and drop. 2) You can queue inside of the driver one packet when you hit the limits unexpectedly, netif_stop_queue(), and return success. Spit this packet out right before waking the queue again. Really, there are no hard reasons to ever return TX_BUSY, it's always a bug. In fact, I want to move things more and more towards the driver queueing TX packets internally instead of the networking mid-layer. That will ahve benefits for things like TX multiqueue, we won't need any locking at all, nor have any knowledge about multiple queues at all, if the driver takes care of providing the buffer between what the kernel gives it and what the device can handle at the moment. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
