qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support


From: Nicholas A. Bellinger
Subject: Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support
Date: Wed, 24 Nov 2010 20:32:23 -0800

On Wed, 2010-11-24 at 19:14 +0000, Stefan Hajnoczi wrote:
> On Wed, Nov 24, 2010 at 5:04 PM, Christoph Hellwig <address@hidden> wrote:
> > 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.
> 
> With userspace iSCSI initiator support setup becomes easy, portable,
> and doesn't require admin privileges:
> qemu -drive file=iscsi:...
> 
> That's pretty compelling.  I don't know if people who already use
> iSCSI today will want to switch but it provides an easy entry into
> iSCSI.
> 

So I have had a bit of experience with the VirtualBox iSCSI initiator,
which is similar in the sense that it also runs in userspace, and is
independent of the host OS, etc..  The primary issue tends to be the
threading model, ie: that the stack is limited to a single thread, which
makes it very limiting in terms of scaling (in my experience) at
1 Gb/sec speeds.

But existing code aside, I think having a small userspace iSCSI
initiator built into QEMU that 'just works' across all host environments
would be a pretty useful thing, even if the scalibility / scope is
limited compared to existing kernel host level iSCSI initiator stacks,
et al.  I have not yet had a chance to look at Ronnie's code, but would
be interested to understand how the threading model currently functions.

Ronnie, I would recommending following Kevin's earlier advice and split
your work into a reviewable series of commits (preferrably generated by
git-format-patch) and repost the series for feedback to qemu-devel.  You
can read that as coded language for 'you will want to learn git to
submit your patch', but it really does work.  ;)

--nab




reply via email to

[Prev in Thread] Current Thread [Next in Thread]