SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iscsi: unsolicited data question




    Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed.

    Julo


    Dennis Young <dyoung@rhapsodynetworks.com>

    06/13/2002 04:00 AM
    Please respond to Dennis Young

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
            Subject:        RE: iscsi: unsolicited data question

           


    Thanks to yours and others' explanation, now I am more clear, but I have
    another question:
     
    Based on your reply, and let me emphasize it by repeating the 4th paragraph
    on page 42 of draft 12-98:
        "... If any non-immediate unsolicited data are sent, the total unsolicited
        data MUST be either the negotiated amount or all the data if the total
        amount is less than the negotiated amount for unsolicited data. ..."
     
    With this rule, do we still need the F bit in the Data-out (both for the solicited
    and unsolicited Data-out)?  The F bit seems redundant since the target has
    enough information to figure out the final unsolicited Data-out and the final
    solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength
    in the Data-out, and the ExpectedDataTransferLength in the corresponding
    SCSI Write PDU).
     
    Thanks,
    Dennis
     
    -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Wednesday, June 12, 2002 11:21 AM
    To:
    Dennis Young
    Cc:
    ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject:
    RE: iscsi: unsolicited data question


    You are wrong about waiting - read my previous text.

    You need unsolicited as the amount in one PDU may not be all you want.


    Julo


    Dennis Young <dyoung@rhapsodynetworks.com>
    Sent by: owner-ips@ece.cmu.edu

    06/12/2002 08:49 PM
    Please respond to Dennis Young

           
           To:        Julian Satran/Haifa/IBM@IBMIL

           cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu

           Subject:        RE: iscsi: unsolicited data question


         



    Are you saying that, for a session that has InitialR2T=No in effect, the initiator

    must send all its data as unsolicited first, up to the amount negotiated in
    FirstBurstSize, before it waits for a R2T from the target?

     

    Can you shed some light on why we need unsolicited Data-out PDU when there
    is ImmediateData, seems like they both serve the same purpose, having both of
    them only make the spec more complex.

     

    Thanks,

    -Dennis

     

    -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Wednesday, June 12, 2002 10:19 AM
    To:
    Dennis Young
    Cc:
    ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject:
    RE: iscsi: unsolicited data question



    This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>

    Neither bandwidth nor latency are wasted.


    Julo

    Dennis Young <dyoung@rhapsodynetworks.com>

    06/12/2002 08:05 PM
    Please respond to Dennis Young

           
          To:        Julian Satran/Haifa/IBM@IBMIL

          cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu

          Subject:        RE: iscsi: unsolicited data question


         




    Julian,


    This leads me to a more interesting question.

    A session with InitialR2T=No in effect, i.e. unsolicited Data-out

    allowed, could cause unintended waste of bandwidth, depending on

    how fast the target sends our R2T in response to the SCSI Write.


    If the target sees the unsolicited Data-out PDU before building the

    R2T, then everything is fine.
    If the target doesn't see the unsolicited Data-out PDU before building

    the R2T, the R2T would request the same portion of data in the

    unsolicited Data-out, thus bandwidth is wasted.


    The question is, how can a target be smart about this?

    Should the target wait a moment for the possible unsolicited Data-out
    after receiving each SCSI Write, this sounds kludgy.


    Also, why do we need the unsolicited Data-out PDU feature when

    there is ImmediateData?


    Regards,

    Dennis


    -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Wednesday, June 12, 2002 6:05 AM
    To:
    Dennis Young
    Cc:
    ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject:
    Re: iscsi: unsolicited data question



    yes - julo
    Dennis Young <dyoung@rhapsodynetworks.com>
    Sent by: owner-ips@ece.cmu.edu

    06/12/2002 06:20 AM
    Please respond to Dennis Young

           
         To:        ips@ece.cmu.edu

         cc:        

         Subject:        iscsi: unsolicited data question


       





    I have a question which has been asked before, but I couldn't find a direct
    answer in the archive.  The table on page 200 of draft 12 doesn't directly
    answer this question either.

    The first paragraph on page 36 of draft 12 says "Targets operate in either
    solicitied (R2T) data mode or unsolicited (non R2T) data mode."
    tells me that a target, at all times during a data sequence transfer, can be

    one or the other, but not both (non R2T for the initial data out, R2T for
    the
    remaining data).  Is this correct?

    Thanks,
    Dennis

    ---snip from an old email dated 3/30/2001---

    " Hi Julian
    Sorry if I'm covering old ground... Is it possible to use unsolicited data
    for the first burst and then request any remaining data using R2T? For
    example, if the target has a previously allocated buffer available (length
    defined by FirstBurstSize) for unsolicited data, then once the initiator has

    sent unsolicited data up to and including this amount then the remaining
    data (if any) can be requested using R2T once the target has the buffer
    space available.
    ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
    matthewb@bri.hp.com "










Home

Last updated: Thu Jun 13 13:18:41 2002
10757 messages in chronological order