All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Kolbe <l-lists@einfachkaffee.de>
To: Avi Kivity <avi@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: tun/tap and Vlans (was: Re: Network I/O performance)
Date: Tue, 19 May 2009 09:18:11 +0200	[thread overview]
Message-ID: <1242717491.28272.12.camel@larosa> (raw)
In-Reply-To: <4A107E3A.9050209@redhat.com>

Hi all,

On a sidenote:

> > I have also realized that when using the tun/tap configuration with
> > a bridge, packets are replicated on all tap devices when QEMU writes
> > packets to the tun interface. I guess this is a limitation of
> > tun/tap as it does not know to which tap device the packet has to go
> > to. The tap device then eventually drops packets when the
> > destination MAC is not its own, but it still receives the packet 
> > which causes more overhead in the system overall.
> 
> Right, I guess you'd see this with a real switch as well?  Maybe have 
> your guest send a packet out once in a while so the bridge can learn its 
> MAC address (we do this after migration, for example).

Does this mean that it is not possible for having each tun device in a
seperate bridge that serves a seperate Vlan? We have experienced a
strange problem that we couldn't yet explain. Given this setup:

Guest            Host          
kvm1 --- eth0 -+- bridge0 --- vlan1 \
               |                     +-- eth0
kvm2 -+- eth0 -/                     /
      \- eth1 --- bridge1 --- vlan2 +

When sending packets through kvm2/eth0, they appear on both bridges and
also vlans, also when sending packets through kvm2/eth1. When the guest
has only one interface, the packets only appear on one bridge and one
vlan as it's supposed to be.

Can this be worked around?

-- 
Lukas



  parent reply	other threads:[~2009-05-19  7:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12  0:28 Network I/O performance Fischer, Anna
2009-05-13  7:23 ` Avi Kivity
2009-05-13 15:56   ` Fischer, Anna
2009-05-17 21:14     ` Avi Kivity
2009-05-19  1:30       ` Herbert Xu
2009-05-19  4:53         ` Avi Kivity
2009-05-19  7:18       ` Lukas Kolbe [this message]
2009-05-19  7:45         ` tun/tap and Vlans Avi Kivity
2009-05-19 19:46           ` Lukas Kolbe
2009-05-20 10:25           ` Fischer, Anna
2009-05-20 10:38             ` Avi Kivity
2009-05-19 21:22       ` Does KVM suffer from ACK-compression as you increase the number of VMs? Andrew de Andrade
2009-05-20 10:15       ` Network I/O performance Fischer, Anna

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=1242717491.28272.12.camel@larosa \
    --to=l-lists@einfachkaffee.de \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.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.