Re: [PATCH 08/13] iscsi-target: Add CHAP Authenticationsupport using libcrypto

[Nicholas A. Bellinger]

On Sat, 2011-07-23 at 22:08 -0500, Mike Christie wrote:
> On 07/23/2011 04:17 PM, Nicholas A. Bellinger wrote:
> > 
> > And, we have also seen historically how painful the split has been with
> > open-iscsi, which in the end took much longer to get stable (and is
> > still harder to debug) than if a proper login split was used to begin
> > with.
> 
> Here is my 2 cents from working on open-iscsi.
> 
> The split did not really have much to do with the initial stability in
> the data paths. It was more due to it getting merged with very little
> real world testing.
> 
> There were stability issues with the interface because no one ever tried
> creating a hw iscsi driver for it before it got merged, because software
> iscsi does a host per session and hw drivers ended up doing a host per
> port or some pci resource, and then boot support.
> 
> Most bugs fixed were due to skb handling, locking/atomic issues,
> spec/rfc issues - not interface issues. But many large changes had to be
> done to make the initial code support hw iscsi.
> 
> I agree open-iscsi is more difficult to debug than initiators that were
> mostly in kernel like iscsi_sfnet. For open-iscsi the userspace part is
> a single process, many operations cannot block, it has a ulgy state
> model. And how it did its split does make things more difficult, because
> it breaks up every operation into a different userspace to kernel call
> (create a session is a call, create a conn is a call, pass a setting is
> a call, bind a conn to a session is call, start the conn is a call,
> etc). For software iscsi if open-iscsi just logged in to the target,
> then passed everything to the kernel in one call then it would have been
> a lot easier to debug. If Tomo's design does not have those issues then
> it seems like it would not be that bad for software iscsi.
> 

In the various kernel/user split implementations, I completely agree
that the open-iscsi is more difficult and painful than what Tomo has
proposed..

However, my main issue is still with moving the default login paths to a
single threaded userspace daemon that needs to be fully aware of lots of
dynaminc state changes in /sys/kernel/config/target/iscsi.  Implementing
a userspace daemon that needs to be aware of this is going to require an
kernel/user split quickly moving towards the 'break up every operation
into a different call' arena, that puts us back open-iscsi type split
terrority.

> I think where doing a kernel/userspace split is going to be more
> difficult is with supporting hw iscsi targets. With software iscsi you
> can just pass down a socket and the settings more or less. With hw
> iscsi, you want to be able to send the login related packets through the
> iscsi port using the iscsi engine or hw/fw might be doing the actual
> login process. But, if you are putting discovery (isns, sendtargets,
> dhcp iscsi/isns options, slp, etc) in userspace then you have to solve
> those issues for discovery so you can use the same interfaces for both.

Fair point.  I would also expect HW iscsi to integrate into the same
control plane and python library for an consistent API to application
devels here.

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/