Subject: [Ips] iSCSI cmd ordering and tagged task

From: dan yo <[email-masked]>
Date: Tue, 18 Nov 2003 21:03:47 -0800 (PST)

It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.  Is my concern valid?
Thanks,
Dan

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

---

From: Julian Satran <[email-masked]>
Date: Wed, 19 Nov 2003 09:20:40 +0200

I do not think your concern is valid.  The skew introduced by multiple 
connections - when those operate correctly - is minimal.
The iSCSI ordering requirement serves mainly to detect missing commands 
due to digest errors (not caught by TCP) and not to impose a SCSI 
ordering.
It helps also avoiding having the initiator overrun the target beyond with 
more than the later can digest without using slow interlock.

Julo

dan yo <[email-masked]> 
Sent by: [email-masked]
19/11/2003 07:03

To
[email-masked]
cc

Subject
[Ips] iSCSI cmd ordering and tagged task

It seems that the iSCSI requirement of preserving command ordering would 
reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, 
if a host has several I/O tasks to send to the target and that the 
ordering is not important, it may want to tag them as "Simple" and let the 
target rearrange them in a way that is optimal to disk access.  However, 
when these tasks arrive out of sequence at the iSCSI target side 
(different from the order in which they enter the iSCSI layer at the 
initiator side), they will be held up to wait for their predecessor to 
arrive before they can be delivered to the SCSI target.  This will a 
bigger issue with the multiple connections per session scenario in iSCSI 
where commands from different connections will get out of order more often 
than not.&n! bsp; Is my concern valid?
Thanks,
Dan
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

---

From: dan yo <[email-masked]>
Date: Wed, 19 Nov 2003 16:28:19 -0800 (PST)

I agree, network latency is insignificant in comparision to disk latency.  My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session.  An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA).  As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup.   The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. 
Thanks,
-Dan   

Julian Satran <[email-masked]> wrote:

I do not think your concern is valid.  The skew introduced by multiple connections - when those operate correctly - is minimal. 
The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering. 
It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock. 

Julo 

[email-masked] cc

It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? 
Thanks, 
Dan

---

From: Julian Satran <[email-masked]>
Date: Thu, 20 Nov 2003 08:09:57 +0200

Our assumption was that the SCSI layer will reside outside the port and it 
can hand-over the CmdSN to the port with the command (and perhaps the 
SCSI-Tag if that is to be different than the iSCSI tag).  I am aware that 
many hardware adapters for reasons of they own have chose to generate 
their own CmdSN and break this assumption.

Julo

20/11/2003 02:28

To
Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc

Subject
Re: [Ips] iSCSI cmd ordering and tagged task

I agree, network latency is insignificant in comparision to disk latency. 
My real concern is the complexity in dealing with session wide variables 
(cmdSN is one) in a device that supports multiple connections per session. 
 An example is the case where each connection (of a multi-connections 
session) terminates on different ingress (host facing) port of a gateway 
(iSCSI to FC, or iSCSI to SATA).  As much as possible, I want to route the 
I/O from each ingress port directly to the egress port (target facing) 
without any inter-ingress port synchronization or lookup.   The SCSI 
'Simple' task seem to be an ideal candidate for that, but the cmdSN 
ordering gets in the way. 
Thanks,
-Dan 

Julo 

To
[email-masked] 
cc

Subject