All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Yusupov <dmitry_yus@yahoo.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Luben Tuikov <luben_tuikov@adaptec.com>,
	open_iscsi <ESQuicksall_open_iscsi@Comcast.net>,
	Mike Christie <michaelc@cs.wisc.edu>,
	'SCSI Mailing List' <linux-scsi@vger.kernel.org>,
	open-iscsi@googlegroups.com
Subject: Re: [PATCH RFC 2/2] implement transport scan callout for iscsi
Date: Wed, 25 May 2005 11:32:11 -0700	[thread overview]
Message-ID: <1117045931.16262.149.camel@beastie> (raw)
In-Reply-To: <1117044247.5210.15.camel@mulgrave>

On Wed, 2005-05-25 at 14:04 -0400, James Bottomley wrote:
> On Wed, 2005-05-25 at 11:18 -0400, Luben Tuikov wrote:
> > MC/S in iSCSI can be seen as a "wide port" in SAS.
> > 
> > That is, commands are ordered, nexus is the same, going to the same port,
> > etc, etc, etc.  MC/S, has nothing to do with multipathing, which sits above
> > the nexus level.  With MC/S the nexus is the same.
> 
> When I use the term "multi-pathing" I mean multiple virtual paths may be
> traversed to get a command from an application to a target device.
> Under that definition, dm-multipath, MC/S and even network bonding are
> all examples of multi-pathing.
> 
> The visibility of the coding is what I have an issue with.  bonding
> could be inherited invisibly from the network but MC/S has to be
> explicitly coded in the software initiator whereas dm-multipath is done
> above the driver: one code base for all multi-path implementations.
> 
> > MC/S is a good thing.
> 
> a) It's optional, so you can't rely on it.
> b) it requires explicit coding in the driver which is a big negative
> since you can't leverage our existing multi-path code (i.e. more bug
> prone)
> c) The feature set it provides to Linux is identical to the feature set
> that dm-multipath provides.
> 
> It's pointless to add support for an optional feature that provides no
> additional benefit (and its detrimental when the only addition is a
> potential negative impact to the code quality).

Those are very strong arguments against having MC/S implemented for the
software iSCSI initiator. Especially true is (a). Not that many targets
offers MC/S, since according to RFC it implies ERL=2.

Now, back to open-iscsi initiator business and its mainline acceptance.
We are going to met your requirement and will remove multi-connection
support before next patch-set submission. As Mike C. mentioned before,
it is fairly easy to do since the whole connection management resides in
user-space. Though it will exists as a kernel patches on our web site
(http://www.open-iscsi.org) for those who wonders.

Are there are some other requirements we need to met besides MC/S
removal ?

Thanks for the good explanation of your point of view!
Dima

> James
> 
> 


  reply	other threads:[~2005-05-25 18:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42936441.0b798bab.39a4.ffff9774SMTPIN_ADDED@mx.googlegroups.com>
2005-05-24 21:01 ` [PATCH RFC 2/2] implement transport scan callout for iscsi Mike Christie
2005-05-24 23:17   ` James Bottomley
2005-05-25  0:25     ` open_iscsi
2005-05-25  1:00       ` James Bottomley
2005-05-25  1:28         ` open_iscsi
2005-05-25  5:22           ` Dmitry Yusupov
2005-05-25 12:55             ` open_iscsi
2005-05-25 13:00           ` Ming Zhang
2005-05-25 13:08             ` open_iscsi
2005-05-25 15:18         ` Luben Tuikov
2005-05-25 18:04           ` James Bottomley
2005-05-25 18:32             ` Dmitry Yusupov [this message]
2005-05-25 19:42               ` James Bottomley
2005-05-26  1:38             ` open_iscsi
2005-05-25  2:20 open_iscsi
  -- strict thread matches above, loose matches on Subject: below --
2005-05-21 21:39 Mike Christie
2005-05-24 17:09 ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1117045931.16262.149.camel@beastie \
    --to=dmitry_yus@yahoo.com \
    --cc=ESQuicksall_open_iscsi@Comcast.net \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luben_tuikov@adaptec.com \
    --cc=michaelc@cs.wisc.edu \
    --cc=open-iscsi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.