On 04/13/2011 04:33 PM, Avi Kivity wrote:
On 04/13/2011 04:02 PM, Ingo Molnar wrote:
* Asias He<asias.hejun@xxxxxxxxx> wrote:
> >> Here are some scp performance test for differenct implementations:
> >> None of rx and tx as thread:
> >> guest to host 3.2MB/s
> >> host to guest 3.1MB/s
> >>
> >> Only rx as thread:
> >> guest to host 14.7MB/s
> >> host to guest 33.4MB/s
> >>
> >> Both rx and tx as thread(This patch works this way):
> >> guest to host 19.8MB/s
> >> host to guest 32.5MB/s
> >>
> >> Signed-off-by: Asias He<asias.hejun@xxxxxxxxx>
> >
> > This is already in master. Thanks!
> >
>
> Ingo suggested to CC the updated version of this patch to kvm
list. So I
> am posting this patch again.
Thanks Asias, cool stuff.
Maybe other KVM developers want to chime in about how to best implement
transparent (non-TAP-using) guest-side networking.
The best approach would be to not go down as low as the IP/Ethernet
packeting
level (it's unnecessary protocol overhead), but to implement some
sort of
streaming, virtio based TCP connection proxying support.
Strictly talking the guest does not need ICMP packets to have working
Internet
connectivity - only passing/tunneling through TCP sockets would be
enough. The
following highlevel ops are needed:
- connect/shutdown/close
- send/receive
- poll
And would be passed through to the host side and mirrored there into
real
connect/shutdown TCP socket ops and into send/receive ops.
The guest OS does not need to be 'aware' of this in any way, as long
as the
bzImage has this magic guest tunneling support included.
Obviously, such a highlevel approach would be much faster as well
than any
packet level virtual networking approach.
Does something like this exist upstream, or do we have to implement it?
macvtap does non-privileged setupless networking.
But this doesn't really answer your message. No, there is no tcp-level
virtio device. However, because of GSO/GRO, I don't think there is a
huge win to be gained by bypassing the lower layers. If you want to
send a megabyte's worth of data into a tcp stream, you prepend a header
and post it to virtio-net, and this goes all the way down to the real
device.
I'm not sure tcp-offload like you propose would pass netdev@. Similar
approaches for real hardware were rejected since they would bypass the
tcp stack. Things like netfilter would no longer work.
--
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
