RE: iSCSI & Linked Commands

[Charles Monia <cmonia@NishanSystems.com>]

Hi Santosh:

See below.

> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Tuesday, April 17, 2001 3:43 PM
> To: Charles Monia
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI & Linked Commands
> 
> 
> Charles Monia wrote:
>  
> > > Mark has already replied to your question on why linked 
> commands won't
> > > work given today's implementations. In most cases, the 
> initiator task
> > > tag is either generated in the HBA driver or in the HBA firmware.
> > 
> > The fact that some adapter implementations on some 
> interconnects may not
> > support linked commands does not grant a license to delete 
> the capability
> > from the protocol specification.
> 
> Charles,
> 
> I was'nt saying that iSCSI must not support linked commands. See my
> comment on this :
> 

Point taken, sorry for the misunderstanding on my part.

<stuff deleted>

> The more interesting question is :
> Is there any particular reason connection allegiance would rather be
> enforced per command than per task ? (if linked commands are un-used,
> this is a moot question....). If it were enforced per task, then, an
> Abort Task would effectively flush all stale PDUs of that 
> task ensuring
> no stale PDUs in the network upon I/O termination at the initiator.
> 

I don't see how the stale PDU scenario comes about. As Julo stated earlier,
the initiator doesn't send the next command in the chain until it receives
status for the previous one.  So, at any time, there should only be PDUs in
flight for one command in a linked command sequence.

In that respect, I believe connection alliegance per command gives
marginally better opportunity for load balancing, since the initiator can
launch the next command in the chain on the most appropriate TCP connection.

Charles