SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iscsi : DataPDULength can differ in each direction.



    Pat,
    
    Sorry for my previous response. I have tried to re-examine the things on my
    own end. I think i am going to agree with you. I donot think buffer
    complexity will be any issue as the two things can be very easily handled.
    but i do have one doubt at this moment for buffer management: 
    
    If the dataPDUSize as informed by the responder is very high and initiator
    cannot supply that high PDU size because it does not have enough capacity to
    make that huge amount of dataPDUSize , dont u think it will paralyze the
    initator's end. ( i might be wrong, but i think there is a limit to sender's
    buffer sending capacity as well. And if that is so then there has to be a
    negotiation of the dataPDUSize.
    
    Sanjeev
    
    -----Original Message-----
    From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
    Sent: Friday, October 05, 2001 2:26 AM
    To: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Santosh Rao'; Rod Harrison
    Cc: Ayman Ghanem; ips@ece.cmu.edu
    Subject: RE: iscsi : DataPDULength can differ in each direction.
    
    
    Sanjeev,
    
    I don't see how allowing each side to independently specify the
    DataPDULength it can accept complicates anything. If Device X can receive 10
    Kbyte PDUs and Device Y can only receive 2 Kbyte PDUs, then the implication
    of allowing them to be independent is
    
      Device X can only send 2 Kbyte PDUs to Device Y - it has to obey Device
    Y's input limitations.
    
      Device Y may send 10 Kbyte PDUs to Device X if it has that capability or
    it can send 2 Kbyte PDUs if its transmit side isn't able to send longer
    ones. The transmitter isn't required to send the maximum PDU size that the
    receiver can handle.
    
    Furthermore, in many cases buffer pools will be shared among multiple
    connections. Therefore a buffer management strategy that depends upon the
    max PDU length would be non-ideal.
    
    Pat
    
    -----Original Message-----
    From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com]
    Sent: Wednesday, October 03, 2001 3:26 PM
    To: 'Santosh Rao'; Rod Harrison
    Cc: Ayman Ghanem; ips@ece.cmu.edu
    Subject: RE: iscsi : DataPDULength can differ in each direction.
    
    
    All,
    
    I think making DataPDULength different on two side will bring complexity in
    implementation. Calculation of CRC, handling unknown and very high value of
    DataPDUlength, change in buffer management code etc etc and above all.. a
    radical change so late in the specs chould be avoided.
    
    In my view we rather can choose for either of the two ways
    1. Either make DataPDULength as list negotiation, which makes sure that the
    computing party choses a result which other party will definitley support
    
    or 
    2. keep it like numeric negotiation with result being computed by responding
    party and double checked by the offering party. In case there is still any
    error when the offering party gets the result, they may either go for reject
    or re-nogotiation.
    
    Sanjeev
    
    -----Original Message-----
    From: Santosh Rao [mailto:santoshr@cup.hp.com]
    Sent: Wednesday, October 03, 2001 11:46 PM
    To: Rod Harrison
    Cc: Ayman Ghanem; ips@ece.cmu.edu
    Subject: Re: iscsi : DataPDULength can differ in each direction.
    
    
    Rod,
    
    The issue came up as a result of Deva pointing out that an initiator may
    not be able to function with the minimal of the 2 DataPDULengths
    (initiator's & target's) in the case where the value chosen was not its
    value.
    
    In order to allow for such implementations that had issues with the
    DataPDULength, I raised this question. 
    
    The benefit of both sides being allowed different DataPDULengths is :
    
    a) Each side can specify its max supported value which the other side
    would not exceed. The sender & receiver would be able to function with
    different DataPDULengths, with the guarantee that their advertised
    receive pdu length will not be exceeded, thus, allowing more flexible
    interoperability of implementations. (btw, the proposal should have read
    : Each side is allowed to advertise its maximum receive pdu length.)
    
    b) It may also allow 2 parties with differing PDU lengths to send larger
    sized PDUs in one direction to the party that advertised a higher
    receive pdu length.
    
    However, I do admit there's a cost to making this change, given we are
    so late in the draft rev and several implementations have already been
    made. If this is not an issue of concern to the majority of
    implementations, I am ok with the current definition, although it is
    more limiting on implementations.
    
    
    Thanks,
    Santosh
    
    
    Rod Harrison wrote:
    > 
    >         Can someone give a tangible benefit to this that can outweigh the
    > spec and implementation churn at this late stage of the game?
    > 
    >         From my point of view the benefit of asymmetric PDU sizes would
    have
    > to be very large to make it worth the extra complexity in buffer
    > management code alone.
    > 
    >         - Rod
    > 
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Ayman Ghanem
    > Sent: Wednesday, October 03, 2001 8:29 PM
    > To: ips@ece.cmu.edu
    > Subject: RE: iscsi : DataPDULength can differ in each direction.
    > 
    > Well, the proposal says:
    > 
    >         Each side should be allowed to specify the DataPDULength it will
    be
    >         using and there should be no attempt to negotiate this value.
    Rather,
    >         the key is exchanged in either direction to inform the other side
    as
    > to
    >         what sized PDUs it should expect.
    > 
    > So, I understand that as if the initiator sends
    > DataPDULength=reallyBigNumber, then it is informing the target that
    > this is
    > what it will be using, but the target should not attempt to negotiate
    > it.
    > 
    > -Ayman
    > 
    > > -----Original Message-----
    > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf
    > Of
    > > Buck Landry
    > > Sent: Wednesday, October 03, 2001 2:13 PM
    > > To: ips@ece.cmu.edu
    > > Subject: RE: iscsi : DataPDULength can differ in each direction.
    > >
    > >
    > > It may add complexity, but, since DataPDULength is only a boundary
    > on
    > > the maximum number of bytes transmitted in a Data PDU (not the
    > minimum),
    > > "the first" *does* have a say about it.  Right?
    > >
    > > -----Original Message-----
    > > From: Ayman Ghanem [mailto:aghanem@cisco.com]
    > > Sent: Wednesday, October 03, 2001 1:38 PM
    > > To: ips@ece.cmu.edu
    > > Subject: RE: iscsi : DataPDULength can differ in each direction.
    > >
    > >
    > > I think this will add unnecessary complexity, specially for data
    > CRCs
    > > having
    > > to be calculated based on two different PDU sizes for Reads and
    > Writes.
    > > Also, one end may choose to do data digests in software. If the
    > other
    > > end
    > > decides to use a really large PDU length (and the first doesn't have
    > a
    > > say
    > > about it), this could be a problem.
    > >
    > > -Ayman
    > >
    > > <snip>
    > >
    
    -- 
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################
    


Home

Last updated: Fri Oct 05 19:17:25 2001
7083 messages in chronological order