From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lyv0x-0003tE-R3 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 17:38:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lyv0s-0003qM-SQ for qemu-devel@nongnu.org; Tue, 28 Apr 2009 17:38:54 -0400 Received: from [199.232.76.173] (port=53661 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lyv0s-0003qD-FB for qemu-devel@nongnu.org; Tue, 28 Apr 2009 17:38:50 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:33653) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lyv0r-0003xe-UU for qemu-devel@nongnu.org; Tue, 28 Apr 2009 17:38:50 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n3SLcG9V010081 for ; Tue, 28 Apr 2009 15:38:16 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n3SLcm6p087598 for ; Tue, 28 Apr 2009 15:38:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n3SLcmKw001657 for ; Tue, 28 Apr 2009 15:38:48 -0600 Message-ID: <49F77766.2080309@us.ibm.com> Date: Tue, 28 Apr 2009 16:38:46 -0500 From: Anthony Liguori 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> <200904281846.19363.paul@codesourcery.com> <49F74199.5030503@us.ibm.com> <200904281928.32369.paul@codesourcery.com> In-Reply-To: <200904281928.32369.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 , Marcelo Tosatti , qemu-devel@nongnu.org, Markus Armbruster Paul Brook wrote: > On Tuesday 28 April 2009, Anthony Liguori wrote: > >> Paul Brook wrote: >> >>> Hmm, in that case I don't understand your distinction between frontend >>> and backend. >>> >> In the case of networking, they don't have to be distinct because all >> you need to do is have two "front-ends" and flip the TX/RX queues. >> Although even in this case, someone has to own the MAC address so it's >> not purely symmetric. >> > > 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. So really, what we're talking about is the difference between an API that consists of: net->transmit_packet(data, size) net_receive_packet(data, size) { } verses net->add_transmit_packet(data, size); datum = net->add_receive_packet(data, size); net_notify_received_packets(datum) { } If the device visible API implies a copy, we lack the ability to do zero-copy receive. That's not saying we shouldn't have the VLAN mechanism in QEMU but that should sit above a network backend that would then do the necessary copying. And yeah, that means that we cannot have the tap implementation have an identical API to the devices. This is necessary though from a performance perspective. >> In the general case, that isn't always true for devices. Consider block >> devices, for instance. >> > > You mean the API we expose to the devices v.s. the API we expose to the image > file backends? Or do you mean different layers like ide/scsi v.s. internal > block devices? > I mean the interface IDE/SCSI use to read/write data from a block device is not the same interface that block-qcow2 uses to provide support for qcow2 images. Your argument IIUC is that block devices are not inherently bus oriented and this is certainly true. However, I'm arguing that bus oriented APIs imply copies to the bus which is not something we want to bake into the interface. So my example of block devices are irrelevant because I didn't understand what you originally were commenting on. -- Regards, Anthony Liguori