MC/S can be used to improve band width of a session without using multi-pathing and it belongs in the driver because it is hidden from the upper layers. Think of it like parallel wires, each carrying separate (but sequenced) commands in parallel.
Eddy
----- Original Message ----- From: "James Bottomley" <James.Bottomley@xxxxxxxxxxxx>
To: "Mike Christie" <michaelc@xxxxxxxxxxx>
Cc: <open-iscsi@xxxxxxxxxxxxxxxx>; "'SCSI Mailing List'" <linux-scsi@xxxxxxxxxxxxxxx>
Sent: Tuesday, May 24, 2005 7:17 PM
Subject: Re: [PATCH RFC 2/2] implement transport scan callout for iscsi
On Tue, 2005-05-24 at 14:01 -0700, Mike Christie wrote:> 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.
My current position on MC/S is that it runs counter to the no multi- pathing in the drivers policy, so should not be done.
As far as I can see it's an optional add on to the iSCSI standard which doesn't improve the feature set or provide any value add over the mandatory explicit multi-path support in rfc3720, which is easy to do via dm-multipath.
James
- : 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
