|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Addition of CmdSN in Data-out PDUEddy, I was referring to Sec 2.2.5 Unsolicited data MUST be sent on every connection in the same order in which commands were sent -Sandeep Eddy Quicksall wrote: > > You can't assume the ITT takes a specific order. > > Eddy > > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Thursday, October 11, 2001 10:30 AM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Cc: 'Paul Koning'; ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > If we use the fact that the ITT-ordering of the unsolicited > Data-out PDUs is identical to the ITT-ordering of the commands > sent *within* a connection, then it should be possible to > resolve the Data-out PDUs in a constant-time operation[*1] > No hash and no cmdSN is required keep a per-connection > chain within the command queue and look at its head. > > [*1]There are a couple of exceptions, due to the leeway the > standard provides the initiator on Data-out PDUs. > > -Sandeep > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > 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: Thu Oct 11 14:17:24 2001 7198 messages in chronological order |