From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7sx0-0003Ho-5j
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:48:10 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7swv-0003Fy-Kl
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:48:09 -0500
Received: from [199.232.76.173] (port=48034 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7swv-0003Fv-F1
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:48:05 -0500
Received: from mx1.redhat.com ([209.132.183.28]:11342)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1N7swu-0005t8-UL
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:48:05 -0500
Subject: Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <200911101544.28386.paul@codesourcery.com>
References: <1255028312-28180-1-git-send-email-markmc@redhat.com>
	<200911101544.28386.paul@codesourcery.com>
Content-Type: text/plain
Date: Tue, 10 Nov 2009 15:45:27 +0000
Message-Id: <1257867927.2888.68.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: Mark McLoughlin <markmc@redhat.com>
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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

On Tue, 2009-11-10 at 15:44 +0000, Paul Brook wrote:
> On Thursday 08 October 2009, Mark McLoughlin wrote:
> > Hi,
> >         Here's a series of patches which gets the ball rolling on adding
> > a -netdev option.
> >...
> >         The idea is to de-emphasise the vlan support, and instead make
> > a nic directly connected to a host backend the default and recommended
> > configuration. We want this because it is only with this configuration
> > that we feasibly add optimizations like GSO support or vhost-net.
> 
> If we're going to introduce point-point connections then IMO everything should 
> be a point-point connection. Having separate point-point and multiple-peer 
> cases is just going to come back and bite us later.
> 
> Once you have a symmetric point-point API, negotiation of features (such as 
> offload, filtering, etc) should be relatively straightforward.  Device 
> creation and port connection should be separate events, with feature 
> negotiation occurring at connection. This gives you hotplug for free, and 
> avoids ordering issues.  vlan functionality is implemented via a fairly 
> trivial hub device that has many ports and doesn't implement any of the fancy 
> optional features.

Yep, that's roughly the plan.

Cheers,
Mark.