|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Addition of CmdSN in Data-out PDUI have not verify version 8 is still the same, but version 07-97 had a rule that unsolicited data MUST be sent in the same order as the commands. Thus, there is no need for a search on the ITT. The target just needs to keep of linked list of I/Os waiting on unsolicited data. New commands are added to the tail, any unsolicited data *should* be associated with the I/O at the head of the list. The ITT is used as a sanity check and you're done. What am I missing? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, October 11, 2001 3:21 AM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul
Home Last updated: Fri Oct 12 11:17:31 2001 7208 messages in chronological order |