Date: Wed, 13 Oct 1999 09:42:10 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: freebsd-scsi@freebsd.org Subject: FW: 99-233r2 - SAM-2 TASK SET FULL Clarifications (fwd) Message-ID: <Pine.BSF.4.05.9910130941430.3693-100000@semuta.feral.com>
next in thread | raw e-mail | index | archive | help
Very appropros of the recent discussions. ---------- Forwarded message ---------- Date: Wed, 13 Oct 1999 09:39:23 -0400 From: "Peterson, Gary" <gpeterson@clariion.com> To: "'t10@t10.org'" <t10@t10.org> Subject: FW: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Peterson, Gary" <gpeterson@clariion.com> * I agreee with Dan - Although a BUSY respsonse is a catch-all for many situations, it does free the initiator or retry at his convenience (i.e. after a 'short' delay). The TASK SET FULL should be used when the target is unable to accept the command from that initator at that time, where another initiator might be able to get a command through. I would think the initiator would then wait for a current outstanding command to return before attempting it again. Also, I don't follow Tom's comment of noticable overhead -- returning either status is equally as fast, isn't it? ---------------------------------------------------------------------- Gary S. Peterson CLARiiON Storage Systems (An EMC Business Unit) Phone: 508/480-7150 FAX: 508/480-7913 EMail: gpeterson@clariion.com -----Original Message----- From: Coughlan, Tom [mailto:Tom.Coughlan@COMPAQ.com] Sent: Wednesday, October 13, 1999 8:51 AM To: Lewis, Dan; 't10@t10.org' Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Coughlan, Tom" <Tom.Coughlan@compaq.com> * Dan, I did not intend to equate Task Set Full with Busy. (I was saying that generating either one can require a noticeable amount of overhead in the FC target.) I don't think there is wide-spread agreement with your view that the initiator should delay after receiving Busy status. The reason is because Busy is something of a catch-all status that includes conditions not related to congestion. Examples include contingent allegiance with another initiator, or the device is busy on another port. The initiator can justifiably re-issue the command after a very short delay in these cases. Given the current non-specificity of the standard, I think we have to assume that initiators interpret Busy as "retry with little or no delay", and Task Set Full as "retry after a delay that is adequate for the target to clear the congestion". Eventually I think the standard should specify the Task Set Full backoff policy, and the policy should also require the initiator to reduce the number of commands outstanding to the logical unit, and implement a gradual ramp-up. Tom -----Original Message----- From: Lewis, Dan [mailto:DLewis@clariion.com] Sent: Tuesday, October 12, 1999 6:55 PM To: Coughlan, Tom; 't10@t10.org' Cc: 'ralphoweber@CompuServe.COM'; Elliott, Robert (Hou) Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Lewis, Dan" <DLewis@clariion.com> * Tom, regarding this new restriction, I don't believe it weakens the only method we have for congestion control because Task Set Full is not the *only* method. Somewhere in your message, you casually equate Task Set Full with Busy. I think there is a profound difference. The way I see it, an initiator that receives Busy status should recognize this to mean that the target is congested AND should re-issue the operation after some (arbitrary) delay. But when an initiator receives Task Set Full, that means *that initiator* has reached a water mark that the target does not want it to exceed. This judgement by the target can vary from one implementation to another, but the initiator can be sure that re-issuing the operation after one of it's tasks has completed is the right policy. -Dan Lewis- > -----Original Message----- > From: Coughlan, Tom [mailto:Tom.Coughlan@COMPAQ.com] > Sent: Tuesday, October 12, 1999 5:07 PM > To: 't10@t10.org' > Cc: 'ralphoweber@CompuServe.COM'; Elliott, Robert (Hou) > Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications > > > * From the T10 Reflector (t10@t10.org), posted by: > * "Coughlan, Tom" <Tom.Coughlan@compaq.com> > * > The latest revision of 99-233 creates a new restriction on > logical units, > allowing them to return Task Set Full to an initiator only if there is > already a task in the task set from that initiator. I believe this > restriction is a bad idea, because it weakens the only method > we have for > congestion control, and congestion control is much more > important for the > operation of large SANs than the goals of this proposal. > > I think there is a consensus that the logical unit sends Task Set Full > status to indicate that it is congested, and that the receipt of any > additional work while it is in this state will be > counter-productive. If > initiators continue to send task requests, the logical unit may become > consumed with returning failure status, and will be unable to make any > progress on its backlog. I've been told that some FC > implementations are > particularly prone to this scenario, because the number of > open exchanges > they support is fairly small, and the amount of processing required to > return a Task Set Full (or Busy) is fairly high. > > We need two things to be able to control congestion: 1) the > logical unit > must return Task Set Full to any initiator that issues a task > while the > logical unit is congested, and 2) all initiators must observe > an adequate > backoff when they receive the Task Set Full status. If we > restrict the > logical unit's ability to return Task Set Full, then we are > likely to create > scenarios where congestion can persist for extended periods of time, > resulting in low efficiency and the possibility of command timeouts. > > A second problem with the proposal is that it can be very difficult to > implement in some designs. In the FC example described > above, for example, > the congestion is in the target, not the logical unit. With > the proposed > behavior, the congested target must conditionalize its > behavior on the state > of the logical unit's task set. This is awkward to implement > and consumes > scarce processing time. > > The original goal of proposal 99-233 was to prevent the Task > Set Full status > from being returned to an initiator that does not implement > tagged queuing. > Along the way, this proposal picked up a second goal, namely, > to encourage > initiators to implement a particular backoff policy. The > favored policy is > "if you get a Task Set Full then wait for at least one of > your tasks to > complete before issuing a new task". > > I do not agree with the original goal, because I think that managing > congestion is much more important than allowing initiator > implementations > that do not understand Task Set Full. As I have said, this > is fundamental > to large multi-initiator SANs. > > I do not agree with the second goal, because 1) I have not > seen evidence > that this backoff policy is the best for controlling congestion while > maintaining fairness, 2) any initiator worth its salt already > knows how many > tasks it has issued to the logical unit, 3) no initiator that > will be used > in the open market can rely on a restriction that has been so > recently added > to the standard, and 4)the difficulty of implementing this in > some initiator > designs is greater than the benefit gained. > > I recommend a change to the original text (contained in the attached > message) as follows: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > be returned when the logical unit receives a task and does not > have enough resources to enter the task in the task set. The logical > unit shall return this status regardless of whether the task > is tagged or untagged. It is strongly recommended that the initiator > perform a delay before issuing or re-issuing a task to this > logical unit. > > Tom Coughlan > OpenVMS SCSI & FC Project Leader > Compaq Computer Corporation > 110 Spit Brook Rd. ZKO3-4/U14 > Nashua, New Hampshire 03062-2698 > Phone: 603-884-0933 > Fax.: 603-884-0189 > Mail: tom.coughlan@compaq.com > > -----Original Message----- > From: Ralph Weber [SMTP:ralphoweber@CompuServe.COM] > Sent: Sunday, September 19, 1999 2:58 PM > To: T10, Reflector > Subject: 99-233r2 - SAM-2 TASK SET FULL Clarifications > > * From the T10 Reflector (t10@t10.org), posted by: > * Ralph Weber <ralphoweber@compuserve.com> > * > A proposal for consideration at the November meetings has > been placed on the T10 FTP site as: > > < ftp://ftp.t10.org/t10/document.99/99-233r2.pdf > > > The text of the proposal is as follows. Underline and strikeout > formatting has been removed for ASCII text compatibility. See the > PDF for a fully formatted presentation of the proposal. > > Doc: T10/99-233r2 > Date: 17 September 1999 > To: T10 Technical Committee > From: Ralph Weber, LSI Logic Alternate Member of T10 > Subj: SAM-2 TASK SET FULL Clarifications > > During the May General SCSI Working Group meeting I was asked to > investigate the SAM-2 definition of the TASK SET FULL status. The > results of this investigation and proposed changes were reviewed and > enhanced by the July Working Group meeting. > > After reviewing the proposal twice at the September General SCSI > Working Group meeting, I believe that the changes shown with > strikeouts and underlines below may be acceptable. Please review and > comment, if sufficient comments are received before the November > meeting, I'll revise the proposal again. Also, discussion of 99-232 > has been removed since that proposal has been approved. > > The problem is that the definition of the TASK SET FULL status (5.2) > does not state whether it can be returned for untagged tasks. The > following proposed changes reflect the majority sentiment of the July > Working Group. > > Old text: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > be returned when the logical unit receives a command and does not > have enough resources to enter the associated task in the task set. > > New text minus strikeouts and underlines: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > not be implemented if the logical unit does not support the creation > of tagged tasks. When the logical unit has at least one tagged task > in the task set from an initiator and that same initiator sends a > task that cannot be entered in the task set due to a lack of task set > resources, TASK SET FULL shall be returned, otherwise BUSY shall be > returned. > > Note: Receipt of a second untagged task from the same initiator is an > error case covered in 5.6.2. > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910130941430.3693-100000>