[lkml]   [2011]   [Jul]   [23]   [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 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.

    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.

     \ /
      Last update: 2011-07-24 05:11    [W:0.019 / U:32.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site