SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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