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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
