From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzWc6-00024s-Mz for qemu-devel@nongnu.org; Thu, 30 Apr 2009 09:47:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzWc0-00021T-H6 for qemu-devel@nongnu.org; Thu, 30 Apr 2009 09:47:46 -0400 Received: from [199.232.76.173] (port=39119 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzWbz-00021D-ME for qemu-devel@nongnu.org; Thu, 30 Apr 2009 09:47:39 -0400 Received: from mx2.redhat.com ([66.187.237.31]:50869) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzWby-00044L-Iq for qemu-devel@nongnu.org; Thu, 30 Apr 2009 09:47:39 -0400 Message-ID: <49F9AB7C.7020803@redhat.com> Date: Thu, 30 Apr 2009 16:45:32 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup() References: <1239812969-8320-2-git-send-email-markmc@redhat.com> <200904281928.32369.paul@codesourcery.com> <49F77766.2080309@us.ibm.com> <200904291137.57852.paul@codesourcery.com> In-Reply-To: <200904291137.57852.paul@codesourcery.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Mark McLoughlin , Anthony Liguori , Marcelo Tosatti , qemu-devel@nongnu.org, Markus Armbruster Paul Brook wrote: >>> I'm still not understanding. Ethernet devices are fundamentally based >>> around a bus architecture. "flip the TX/RX queues" only makes sense if >>> you're talking about a point-point connection. For ethernet devices I see >>> no reason to distinguish between "host" devices (slirp, vde, tap) and >>> "guest" devices. They may be created for different reasons, but they're >>> all doing fundamentally the same thing. >>> >> In the bus model, there's an implicit copy-to-the-wire operation that >> results in replication of the packet to everything else on the bus. >> From a performance perspective, this is not at all ideal. >> > > I'm not convinced by this argument. I don't see why a one-many api requires a > copy. > To achieve copyless receive (from guest perspective), you need to give the receive buffer to the transmitting device (tap). If there are more than one transmitting devices, you have a conflict. Sure, you can short-ciruit the case where you have a pair of devices, but then you need to revoke posted receive descriptors. -- error compiling committee.c: too many arguments to function