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
