On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote: > Nope. Being async is critical for copyless networking: > > - in the transmit path, so need to stop the sender (guest) from touching > the memory until it's on the wire. This means 100% of packets sent will > be blocked.
Hi Avi, You keep saying stuff like this, and I keep ignoring it. OK, I'll bite: Why would we try to prevent the sender from altering the packets? > A userspace net interface needs to provide the following: > > - true async operations I'll hold on this pending discussion above. > - multiple packets per operation (for interrupt mitigation) (like > lio_listio) The benefits for interrupt mitigation are less clear to me in a virtual environment (scheduling tends to make it happen anyway); I'd want to benchmark it. Some kind of batching to reduce syscall overhead, perhaps, but TSO would go a fair way towards that anyway (probably not enough). > - scatter/gather packets (iovecs) Yes, and this is already present in the tap device. Anthony suggested a slightly nasty hack for multiple sg packets in one writev()/readv, which could also give us batching. > - configurable wakeup (by packet count/timeout) for queue management I'm not convinced that this is a showstopper, though. > - hacks (tso) I'd usually go for a batch interface over TSO, but if the card we're sending to actually does TSO then TSO will probably win. > Most of these can be provided by a combination of the pending aio work, > the pending aio/fd integration, and the not-so-pending tap aio work. As > the first two are available as patches and the third is limited to the > tap device, it is not unreasonable to try it out. Maybe it will turn > out not to be as difficult as I predicted just a few lines above. Indeed, I don't think we're asking for a revolution a-la VJ-style channels. But I'm still itching to get back to that, and this might yet provide an excuse 8) Cheers, Rusty. - 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