All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Or Gerlitz <ogerlitz@voltaire.com>,
	Herbert Xu <herbert.xu@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend
Date: Wed, 15 Jul 2009 22:52:33 +0100	[thread overview]
Message-ID: <20090715215233.GO3056@shareable.org> (raw)
In-Reply-To: <4A5E44CD.70209@web.de>

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	other threads:[~2009-07-15 21:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01 15:46 [Qemu-devel] [PATCH] net: add raw backend Or Gerlitz
2009-07-01 16:21 ` Jamie Lokier
2009-07-02 12:25   ` Or Gerlitz
2009-07-03  2:39     ` Jamie Lokier
2009-07-07 13:33       ` Or Gerlitz
2009-07-07 14:57         ` Jamie Lokier
2009-07-08 14:45           ` Or Gerlitz
2009-07-14 13:54             ` Or Gerlitz
2009-07-15 20:38             ` Jamie Lokier
2009-07-15 21:06               ` Jan Kiszka
2009-07-15 21:52                 ` Jamie Lokier [this message]
2009-07-16  8:29               ` Or Gerlitz
2009-07-20 14:13               ` [Qemu-devel] [PATCH] net: add raw backend - some performance measurements Or Gerlitz
2009-07-20 15:53                 ` Herbert Xu
2009-07-20 18:20                   ` Michael S. Tsirkin
2009-07-21  1:46                     ` Herbert Xu
2009-07-21  7:03                   ` Or Gerlitz
2009-07-21  7:25                     ` Herbert Xu
2009-07-21  7:25                       ` Herbert Xu
2009-07-21 10:17                       ` Or Gerlitz
2009-07-21 10:17                         ` Or Gerlitz
2009-07-21 10:27                       ` Michael S. Tsirkin
2009-07-21 10:27                         ` Michael S. Tsirkin
2009-07-21 11:05                         ` Or Gerlitz
2009-07-21 11:05                           ` Or Gerlitz
2009-07-21 12:01                           ` Michael S. Tsirkin
2009-07-21 12:01                             ` Michael S. Tsirkin
2009-07-21 12:14                             ` Herbert Xu
2009-07-21 12:14                               ` Herbert Xu
2009-07-21 13:41                               ` Or Gerlitz
2009-07-21 13:41                                 ` Or Gerlitz
     [not found] ` <5b31733c0907011250i7afcdbcdnb844290de4ad64f2@mail.gmail.com>
2009-07-02 12:08   ` [Qemu-devel] [PATCH] net: add raw backend Or Gerlitz
2009-07-02 15:43 ` Michael S. Tsirkin
2009-07-07 14:45   ` Or Gerlitz
2009-07-07 14:49     ` Michael S. Tsirkin
2009-07-08 14:46       ` Or Gerlitz
2009-07-08 15:06       ` Or Gerlitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090715215233.GO3056@shareable.org \
    --to=jamie@shareable.org \
    --cc=herbert.xu@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=ogerlitz@voltaire.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.