Subject: RE: Fw: [Ips] iSCSI: abort task set

From: "Ramesh Mangamuri" <[email-masked]>
Date: Mon, 2 Feb 2004 17:49:13 -0800

If I understood this discussion correctly and 10.5.1, I didn't
understand why we consider about Commands from other sessions from
different initiators. 10.5.1 mentioned clearly that "ABORT TASK SET"
only aborts tasks issued via this session.

-----Original Message-----
From: Julian Satran [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 6:18 AM
To: [email-masked]
Cc: Mallikarjun C.; Eddy Quicksall; [email-masked]; [email-masked]
Subject: Re: Fw: [Ips] iSCSI: abort task set

I might be a bit late and you might have closed on all this but here is 
what I think although I have to admit that I don't recall the debate in 
its entirety

[email-masked] wrote on 30/01/2004 21:33:55:

> On Fri, 30 Jan 2004, Mallikarjun C. wrote:
> 
> > Eddy,
> >
> > Sorry for not responding sooner, I was checking my old
> > notes (but couldn't find relevant ones so far).
> >
> > The authors' advice on this is the following -
> >
> > The wait for affected tasks can be done (need to
> > pick a point in time as the reference for determining
> > the "affected" tasks, regardless of the # of sessions).
> > However, an alternative that's also legal is given below.
> >
> > Bullet (b) should have been:
> >
> > b) Waits for all target transfer tags to be responded to
> >     and for all affected tasks in the task set to be
> >     received (alternatively, the target may plug the CmdSN
> >     gaps for unreceived commands just as if an abort request
> >     is received for each individual affected task, refer
> >     section 6.9 "SCSI timeouts")
> 
> Abort Task Set has to plug the whole CmdSN window on each session??
That
> sounds excessive. Plugging the CmdSN hole for an Abort Task seems
fine,
> since the initiator tells the target explicitly which CmdSN to abort 
(and
> also knows what the highest CmdSN used so far is). But with the Task
Set
> commands, we _don't_ know the highest CmdSN the initiator has used,
only
> the highest CmdSN we've seen and MaxCmdSN.
> 

I don't think that the plugging the holes for other initiators is
required 
even if TST is 0.
The SCSI tasks are what they are an the SCSI task set has to aborted 
accordingly.
However plugging the holes for the specific initiator seems to fall in
the 
realm of iSCSI
and a target may wait or plug as the "bound" of CmdSN is known for that 
session.

And yes abort task-set with TST=0 is messy! (for any transport)

> Also, for the TST 000b case, what does that mean for other initiators?
> Their entire CmdSN window gets filled? Consider an initiator that was
> quiescent. If I'm understanding the window-filling correctly, its
entire
> CmdSN window gets slammed shut. Since its quescent, how will it know
its
> window got closed? Any non-immediate command it sends will just
disapear
> as the CmdSN window was filled. It will also see the CmdSN window just
> move if the target sends in a PDU. It won't understand why the window
> moved of its own accord until it gets a SCSI abort UA. ??
> 
> Finally, since iSCSI tasks don't get passed to the SCSI layer until
the
> CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI 
task
> set?
> 
> Or did I misunderstand something? Please tell me I did as the above 
looks
> messy. :-)
> 
> > Note that the wait on StatSN ack is however
> > mandatory.
> 
> Is there any sort of time out?
> 
> > It is good to get this alternative/clarification into
> > the final RFC.
> 
> Take care,
> 
> Bill
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Mon, 2 Feb 2004 21:49:09 -0800 (PST)

> only aborts tasks issued via this session.

CLEAR TASK SET when TST is 000b does abort tasks from other initiators.

Take care,

Bill