[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] net: add raw backend

From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend
Date: Wed, 15 Jul 2009 22:52:33 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Jan Kiszka wrote:
> > But are you sure it's faster?
> > I'd want to see measurements before I believe it.
> > 
> > If you need any host<->VM networking, most of the time the packet
> > socket isn't an option at all.  Not many switches will 'U turn'
> > packets as you suggest.
> FWIW, the fastest local VM<->VM bridge I've happened to measure so far
> was using qemu's -net socket,listen/connect, ie. a plain local IP or
> unix domain socket between two qemu instances. No tap devices, no
> in-kernel bridges involved.

That's not surprising, but good to know.

Packet sockets aren't much use for VM<->VM bridges either ;-)

However on a positive note, if packet sockets give good performance
for VM<->external, and a unix domain socket gives good performance for
VM<->VM, maybe a packet socket on _lo_ (the loopback interface) can be
used for VM<->host communication?

Then with the right (ugly) hackery in QEMU, it could query the host's
MAC addresses as well as other VMs on the same host, listen on all
three types of interface, and send to the appropriate one depending on
destination MAC address of each packet.

That might give great performance in all cases and solve the bridge
configuration problem at the same time, so that you can run VMs easily
which Just Work(tm) on the host's network.

Then again it might not.  Code would be a bit complicated, it would
interact with Linux iptables differently, and one of the most useful
configurations which is VMs being NAT'd by the host (so invisible
outside the host) would be difficult.

> But this picture may change once we have some in-kernel virtio-net
> backend.

If there's a faster way to send/receive packets, especially if it
_behaves_ differently from tap/packet, it would be nice if it were
available from userspace too, not just from KVM.

If virtio-net is growing a backend to send/receive packets via the
host network stack, it would be nice if it solve the awkward
bridge configuration problem at the same time.

Do you know what direction that backend is going in?  In my experience
with VMs, they are always looked after by some host iptables rules for
safety, and sometimes NAT rules depending on how they are to be
visible outside, and with policy routing at times too.  It would be
great if those facilities still worked, and unfortunate if the new
backend was only usable in quite limited configurations.

-- Jamie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]