[lkml]   [2011]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 08/13] iscsi-target: Add CHAP Authentication support using libcrypto
    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

    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

    > 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.


     \ /
      Last update: 2011-07-24 07:11    [W:0.028 / U:2.532 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site