From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751512Ab1GXFJR (ORCPT ); Sun, 24 Jul 2011 01:09:17 -0400 Received: from mail.linux-iscsi.org ([67.23.28.174]:54161 "EHLO linux-iscsi.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751091Ab1GXFJN (ORCPT ); Sun, 24 Jul 2011 01:09:13 -0400 Subject: Re: [PATCH 08/13] iscsi-target: Add CHAP Authentication support using libcrypto From: "Nicholas A. Bellinger" To: Mike Christie Cc: linux-iscsi-target-dev@googlegroups.com, James Bottomley , Linus Torvalds , target-devel , linux-scsi , linux-kernel , Christoph Hellwig , Andy Grover , Hannes Reinecke , Roland Dreier , Andrew Morton In-Reply-To: <4E2B8C98.2060601@cs.wisc.edu> References: <1311410747-29947-1-git-send-email-nab@linux-iscsi.org> <1311410747-29947-9-git-send-email-nab@linux-iscsi.org> <1311439173.23720.14.camel@mulgrave> <1311445075.17423.13.camel@mulgrave> <1311455867.31450.287.camel@haakon2.linux-iscsi.org> <4E2B8C98.2060601@cs.wisc.edu> Content-Type: text/plain Date: Sat, 23 Jul 2011 21:59:55 -0700 Message-Id: <1311483595.31450.427.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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