Re: [RFC PATCH 00/17] virtual-bus

[Avi Kivity]

Herbert Xu wrote:
> On Thu, Apr 02, 2009 at 12:02:09PM +0300, Avi Kivity wrote:
>   
> > There is no choice.  Exiting from the guest to the kernel to userspace  
> > is prohibitively expensive, you can't do that on every packet.
> >     
>
> I was referring to the bit between the kernel and userspace.
>
> In any case, I just looked at the virtio mitigation code again
> and I am completely baffled at why we need it.  Look at Greg's
> code or the netback/netfront notification, why do we need this
> completely artificial mitigation when the ring itself provides
> a natural way of stemming the flow?
>   

If the vcpu thread does the transmit, then it will always complete 
sending immediately:

 guest: push packet, notify qemu
 qemu: disable notification
 qemu: pop packet
 qemu: copy to tap
 qemu: ??

At this point, qemu must enable notification again, since we have no 
notification from tap that the transmit completed.  The only alternative 
is the timer.

If we do the transmit through an extra thread, then scheduling latency 
buys us some time:

 guest: push packet, notify qemu
 qemu: disable notification
 qemu: schedule iothread
 iothread: pop packet
 iothread: copy to tap
 iothread: check for more packets
 iothread: enable notification

If tap told us when the packets were actually transmitted, life would be 
wonderful:

 guest: push packet, notify qemu
 qemu: disable notification
 qemu: pop packet
 qemu: queue on tap
 qemu: return to guest
 hardware: churn churn churn
 tap: packet is out
 iothread: check for more packets
 iothread: enable notification

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/