Re: QEMU PIC indirection patch for in-kernel APIC work

Rusty Russell
2007-04-11T13:23:14Z

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.