|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE:I would vote for #5 as it is a familiar way of doing things for SCSI folks. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- <http://ecardfile.com/id/shawnce> ------------------------------------------------------- > -----Original Message----- > From: Lawrence J. Lamers [mailto:ljlamers@ieee.org] > Sent: Friday, July 06, 2001 8:05 AM > To: Santosh Rao; ips@ece.cmu.edu > Subject: Re: > > > Mark, Santosh, > > The behavior in #5 is what most SCSI device guys are used to. It is > similar to the way MODE SENSE and other commands work that > return parameter > lists. I would vote for #5. > > > > > At 07/05/2001, Santosh Rao wrote: > >Mark, > > > >IMO, alternative #4 is sufficient and is semantically > aligned with the > >FC-GS-2/GS-3 GID_FT model. > > > >It does require modification of the Text Response PDU to provide a > >Relative Offset (RO) field indicating the RO of the text response > >PDU from the start of the text response payload, in order to > allow initiators > >to correctly re-assemble the received response PDUs. > > > >Regards, > >Santosh > > > > > >Mark Bakke wrote: > > > > > > Initiator developers- > > > > > > Please respond to the questions at the end. > > > > > > Thanks, > > > > > > Mark > > > > > > The current iSCSI draft allows text command and response > > > PDUs of up to 4096 bytes. While we don't see any real > > > problems for the command PDU size, commands such as SendTargets > > > can easily exceed the response size. > > > > > > There are several ways we can fix this. The first two solutions > > > require no differences in the current iSCSI text command and > > > response; the latter three involve the use of the F bit. > > > > > > 1. Assume that such commands are done on a "special" connection > > > or are handled completely in software, and allow its response > > > PDU to be as large as it needs to be. > > > > > > This one appears too restrictive to be a solid solution. It > > > will also weaken any data digests done on the longer PDU. > > > > > > 2. Create an iterative SendTargets key (and do the same for any > > > other text commands that need this), that would allow the > > > initiator to request the "next target" or "next address". > > > > > > This would work, but would require any new command that needed > > > a large response to implement an iterator. It also means that > > > each part of the response from the iterator would have to fit > > > in the 4k PDU. > > > > > > The remainder of these require that only one text command sequence > > > be outstanding on a connection at a given time. They use the F > > > bit to indicate the last PDU of the sequence. Note that > connection > > > allegiance is assumed for the entire sequence, and text commands > > > are never retried on another connection; a new command is issued > > > instead. > > > > > > 3. Do a text-response R2T, where the initiator controls when the > > > next partial response is sent. This would be more generic: > > > > > > I->T Text Command (F bit set) > > > T->I Text Response (first PDU, F bit cleared) > > > I->T Text Command (with some indicator that we want more) > > > T->I Text Response (next PDU, F bit cleared) > > > > > > ... > > > > > > I->T Text Command (with indicator that we want more) > > > T->I Text Response (last PDU, F bit set) > > > > > > The main problem with this is that the target must keep track > > > of the state of its responses; if the initiator just > stops asking, > > > it may have to keep a buffered response around until > it times out, > > > the connection is dropped, or another text command comes along. > > > > > > 4. Allow multiple response PDUs to a single text command: > > > > > > I->T Text Command (F bit set) > > > T->I Text Response (first PDU, F bit cleared) > > > T->I Text Response (next PDU, F bit cleared) > > > > > > ... > > > > > > T->I Text Response (last PDU, F bit set) > > > > > > Basically, we are doing (3) without the R2T. The initiator, > > > upon sending the text command, must be prepared either to > > > accept as many PDUs as come back, or throw them away if it > > > can't handle them. This solution is a lot like #1, but with > > > the response spread across 4k PDUs. > > > > > > Also note that this (and the following scheme) avoid > the problem > > > of the target keeping state; it sends ALL of the response PDUs > > > without the initiator asking for them. > > > > > > 5. Do #4, but allow the initiator to specify the amount of data > > > it is willing to accept: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > > T->I Text Response (first PDU, F bit set, > TotalResponseLength=12288) > > > > > > In the above example, we have created a new text command field: > > > > > > AcceptResponseLength > > > > > > And in the text response PDU: > > > > > > TotalResponseLength > > > > > > The initiator indicated it was willing to accept a 4k response. > > > The target returned the first 4k in the text response, but set > > > the F bit since it was at its limit. It also returned a > > > TotalResponseLength field. Since this was greater than the > > > AcceptResponseLength, the initiator knows the amount of buffer > > > space it will need to get the full response. It can > then choose > > > whether it will re-send the command, and if so, can give it a > > > large enough response length: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > > T->I Text Response (first PDU, F bit clear) > > > T->I Text Response (next PDU, F bit clear) > > > T->I Text Response (last PDU, F bit set, > TotalResponseLength=12288) > > > > > > Note that most initiators will probably send an > AcceptResponseLength > > > of the largest response they would normally accept, > and that most > > > target responses will fit in one or a few PDUs anyway. > > > > > > #5 is really a compromise between #3 and #4; the target has the > > > benefit of being less statefull, and the initiator has > the benefit > > > of controlling the amount of data it receives. > > > > > > I would like to recommend either #4 or #5. I think that #5 is > > > probably the safest solution, but #4 may not be a problem > for anyone. > > > > > > Assuming that none of the implementors of initiators have > a problem > > > with #4, I would pick that. > > > > > > If they do have a problem with it, we should go with #5. > > > > > > Targets probably don't care much whether we do #4 or #5. > > > > > > Initiator developers- > > > > > > Please indicate which solution (#4 or #5) appeals to you. > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > >-- > >################################# > >Santosh Rao > >Software Design Engineer, > >HP, Cupertino. > >email : santoshr@cup.hp.com > >Phone : 408-447-3751 > >################################# > > Regards, > > ========================================== > Lawrence J. Lamers > email: ljlamers@ieee.org > Cell Phone: (408) 234-0071 > Home Phone: (408) 578-1709 >
Home Last updated: Tue Sep 04 01:04:20 2001 6315 messages in chronological order |