lkml.org 
[lkml]   [2009]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 00/17] virtual-bus
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



\
 
 \ /
  Last update: 2009-04-02 11:31    [W:0.151 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site