From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7stb-0007xC-SS for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:44:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7stW-0007m0-Qk for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:44:39 -0500 Received: from [199.232.76.173] (port=46346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7stW-0007jl-Go for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:44:34 -0500 Received: from mx20.gnu.org ([199.232.41.8]:39301) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N7stV-0005BO-4q for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:44:33 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7stS-0004wp-SX for qemu-devel@nongnu.org; Tue, 10 Nov 2009 10:44:31 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option Date: Tue, 10 Nov 2009 15:44:28 +0000 References: <1255028312-28180-1-git-send-email-markmc@redhat.com> In-Reply-To: <1255028312-28180-1-git-send-email-markmc@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200911101544.28386.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Mark McLoughlin 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. Paul