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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
