From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=42422 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PLIlx-0007ar-Ez
	for qemu-devel@nongnu.org; Wed, 24 Nov 2010 12:04:46 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1PLIlu-0001hy-7A
	for qemu-devel@nongnu.org; Wed, 24 Nov 2010 12:04:45 -0500
Received: from verein.lst.de ([213.95.11.210]:55354)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1PLIlt-0001hc-V7
	for qemu-devel@nongnu.org; Wed, 24 Nov 2010 12:04:42 -0500
Date: Wed, 24 Nov 2010 18:04:37 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support
Message-ID: <20101124170437.GG31124@lst.de>
References: <AANLkTinke0r_ub4aqhbzG=LUjrvb4xEyM=5xFQwi1C3h@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTinke0r_ub4aqhbzG=LUjrvb4xEyM=5xFQwi1C3h@mail.gmail.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.nongnu.org/archive/html/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: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, "Nicholas A. Bellinger" <nab@linux-iscsi.org>, Hannes Reinecke <hare@suse.de>

I don't really see the point of this.  It's implemented as a protocol,
and thus the bottom of the qemu protocol stack.  So we might get SCSI
commands in from the guest, decode them, just to re-encode them again
and send them off to the network all inside qemu.

Do you have any performance numbers showing why the addition of the
code is nessecary over just using the kernel iscsi initiator?  Which
btw, is a lot more flexible as it also supports SG_IO passthrough
and thus accessing other devices not supporting the SBC command set.