From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LzaiR-0008Rx-Hy
	for qemu-devel@nongnu.org; Thu, 30 Apr 2009 14:10:35 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LzaiQ-0008Qu-L1
	for qemu-devel@nongnu.org; Thu, 30 Apr 2009 14:10:34 -0400
Received: from [199.232.76.173] (port=39778 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LzaiQ-0008Qd-CO
	for qemu-devel@nongnu.org; Thu, 30 Apr 2009 14:10:34 -0400
Received: from fg-out-1718.google.com ([72.14.220.155]:23156)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1LzaiP-0006Ol-TU
	for qemu-devel@nongnu.org; Thu, 30 Apr 2009 14:10:34 -0400
Received: by fg-out-1718.google.com with SMTP id l27so1232920fgb.8
	for <qemu-devel@nongnu.org>; Thu, 30 Apr 2009 11:10:33 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <49F9E71F.50009@us.ibm.com>
References: <1239812969-8320-2-git-send-email-markmc@redhat.com>
	<200904291137.57852.paul@codesourcery.com>
	<49F9AB7C.7020803@redhat.com>
	<200904301702.32282.paul@codesourcery.com> <49F9D2B3.60707@us.ibm.com>
	<f43fc5580904300957w38c795as24ddfb89b78aaea0@mail.gmail.com>
	<49F9DBCC.3030906@us.ibm.com> <49F9E3CB.4000604@web.de>
	<49F9E71F.50009@us.ibm.com>
Date: Thu, 30 Apr 2009 21:10:32 +0300
Message-ID: <f43fc5580904301110r38ef66bfo90e6cc308ef14bff@mail.gmail.com>
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Mark McLoughlin <markmc@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, Jan Kiszka <jan.kiszka@web.de>, Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>

On 4/30/09, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Jan Kiszka wrote:
>
> > That would only allow one such pair per VM.
> >
> >
>
>  id basically becomes another type of vlan id.  To have multiple nics, you
> do:
>
>  -net tap,vlan=off,id=1234 -net
> nic,model=virtio,vlan=off,id=1234
>  -net tap,vlan=off,id=4321 -net
> nic,model=virtio,vlan=off,id=4321

I think "off" and "id" are not descriptive enough, how about:
 -net tap,vlan=pointopoint,ptop_id=4321 -net
nic,model=virtio,vlan=pointopoint,ptop_id=4321

>  And this goes back to the notion of having all device front-ends/back-ends
> have some sort of identifier to associate one to the other.
>
>
> > Why not keeping all the existing infrastructure, just locking a vlan
> > against becoming more than a point-to-point link once some conflicting
> > optimization was applied? That should be easy to implement and to
> > explain to the user.
> >
> >
>
>  I think you're suggesting the same thing as me, except you are saying make
> vlan=off implicit, and use vlan=XXX instead of id=XXX.
>
>  We can still make vlan=off implicit, and default id=0, so that -net tap net
> nic,model=virtio does the right thing.  However, if a user explicitly says
> -net tap,vlan=1 -net nic,model=virtio,vlan=1, it behaves like it used to.

Nice, though if there are two vlans, one specified without explicit ID
and the other with ID=1, the performance will be different.