From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LitJR-0006AF-Lr for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:35:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LitJN-0006A2-BX for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:35:45 -0400 Received: from [199.232.76.173] (port=43456 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LitJN-00069z-6Q for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:35:41 -0400 Received: from verein.lst.de ([213.95.11.210]:40862) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1LitJM-0002iv-NV for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:35:41 -0400 Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id n2FGZcIF002936 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 15 Mar 2009 17:35:38 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id n2FGZcNw002934 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 17:35:38 +0100 Date: Sun, 15 Mar 2009 17:35:38 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs Message-ID: <20090315163538.GA2724@lst.de> References: <20090314192701.GA3497@lst.de> <20090314192828.GB3717@lst.de> <49BCF79D.8050103@redhat.com> <20090315144843.GC30986@lst.de> <49BD19CF.7030807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BD19CF.7030807@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sun, Mar 15, 2009 at 05:07:59PM +0200, Avi Kivity wrote: > QEMUStaticIOVector qiov; > > qemu_static_iovector_init(&qiov, data, len); > some_random_function(&qiov.iov, ...); > > Of course we need not to free non-owned iovecs. That means more wasted space in every iocb, more special cases needed in the QEMUIOVector to deal with the static allocation special case, etc. I still haven't seen an actual benefit of using the QEMUIOVector at that level. > They allow dropping two extra parameters, but I agree no huge benefit. > I still like them. I think they are good for the use case of actually dynamically building iovecs in the dma helper case. They just aren't the right interface for the block level API. Given that no one underneath that API is going to add more elements to the iovec there's no good reason to carry the memory allocation details around.