On 1
9/2015 3:31 PM, Bart Van Assche wrote:
On 01/09/15 12:39, Sagi Grimberg wrote:
On 1/8/2015 4:11 PM, Bart Van Assche wrote:
On 01/08/15 14:45, Sagi Grimberg wrote:
Actually I started with that approach, but the independent connections
under a single session (I-T-Nexus) violates the command ordering
requirement. Plus, such a solution is specific to iSER...
Which command ordering requirement are you referring to ? The Linux
storage stack does not guarantee that block layer or SCSI commands will
be processed in the same order as these commands have been submitted.
I was referring to the iSCSI session requirement. I initially thought of
an approach to maintain multiple iSER connections under a single session
but pretty soon I realized that preserving commands ordering this way
is not feasible. So independent iSER connections means independent
iSCSI sessions (each with a single connection). This is indeed another
choice, which we are clearly debating on...
I'm just wandering if we are not trying to force-fit this model. How
would this model look like? We will need to define another entity to
track and maintain the sessions and to allocate the scsi_host. Will that
be communicated to user-space? How will error recovery look like?
Hello Sagi,
Hey Bart,
As you probably remember scsi-mq support was added in the SRP initiator
by changing the 1:1 relationship between scsi_host and RDMA connection
into a 1:n relationship.
Of course I remember ;)
I don't know how much work it would take to
implement a similar transformation in the SCSI initiator. Maybe we
should wait until Mike's workday starts such that Mike has a chance to
comment on this.
So the question of the amount of work is not the main concern here.
After all I still think that MCS is a better fit to scsi-mq than coming
up with some other of abstraction layer to manage multiple sessions.
After all, MCS is specified and well defined.
There is the question of cmdsn as a potential synchronization point, but
shouldn't we discuss that instead of trying to get around it? If we
agree that iSCSI session-wide ordering requirements are too restrictive
in most use-cases, why not suggesting some form of relaxed ordering
mode that is would leave ordering to upper layers?
If this kind of mode would appear in the RFC 3720 family, was there
even a question of what we should do?
Sagi.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
