From: Mike Christie <michaelc@cs.wisc.edu>
To: open-iscsi@googlegroups.com
Cc: 'SCSI Mailing List' <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] implement transport scan callout for iscsi
Date: Tue, 24 May 2005 14:01:04 -0700 [thread overview]
Message-ID: <42939610.3070104@cs.wisc.edu> (raw)
In-Reply-To: <42936441.0b798bab.39a4.ffff9774SMTPIN_ADDED@mx.googlegroups.com>
Alex Aizman wrote:
> James Bottomley wrote:
>
>>On Sat, 2005-05-21 at 14:39 -0700, Mike Christie wrote:
>>
>>>`-- session1
>>> |-- connection1:0
>>> `-- target1:0:0
>>> |-- 1:0:0:0
>>
>>I understand that session1 represents the physical connection
>>between the target and the initiator, but what's connection1:0?
>
>
> It's a leading transport connection of the session1 (above). Quoting the
> spec (http://www.faqs.org/rfcs/rfc3720.html):
>
> - According to [SAM2], the I_T nexus is a relationship
> between a SCSI Initiator Port and a SCSI Target Port. For iSCSI,
> this relationship is a session, defined as a relationship between
> an iSCSI Initiator's end of the session (SCSI Initiator Port) and
> the iSCSI Target's Portal Group.
>
> The session itself is not a "physical connection"; it aggregates one or more
> transport connections between a given SCSI Initiator Port and a SCSI Target
> Port. There is always at least one (leading) connection.
>
So just to be clear, open-iscsi can support multiple connections per
session. Do you want us to completely remove this feature for mainline?
I know you and christoph have given me this answer many times before,
but not seeing a reply to Nicholas's question about just disabling may
have created some doubt as to the extent people have to go? Since
open-iscsi pushed the connection management code to userspace, removing
MCS from the driver will not be too terrible a job for us though.
The connection dir for single connection sessions though is just a nice
way to export the kernel structure's info and have it also reflect the
iSCSI RFC's definitions at the same time. For sfnet we used to throw
everything in one dir becuase it did not have a connection structure so
it simplified refcounting.
next parent reply other threads:[~2005-05-24 21:01 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 ` Mike Christie [this message]
2005-05-24 23:17 ` [PATCH RFC 2/2] implement transport scan callout for iscsi 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
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=42939610.3070104@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=linux-scsi@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox