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