SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: new iSCSI draft - 02.txt



    The point is (whether you use an mbuf/mblk/zbuf/socket buffer or whatever)
    some type of manipulation will be required. Bottom line is a periodic marker
    does not work well for a software based implementation. As I've indicated
    before
    I do not believe a framing mechanism is required at this point in time. We
    should start looking at what it will take to use SCTP (or something
    similar).
    When the 10G pipes become available in the future we will then be
    ready/positioned
    and have a solution that should work for all.
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    julian_satran@il.ibm.com
    Sent: Saturday, January 06, 2001 3:08 AM
    To: ips@ece.cmu.edu
    Subject: RE: new iSCSI draft - 02.txt
    
    
    
    
    Dave,
    
    I think that a shim can be inserted between the socket calls and the TCP
    copy to mbuf or from mbuf.
    On many socket implementations this can be achieved by just changing the
    protocol "name" in the socket data structure and then have the shim revert
    it to the original.
    
    However we should not be very concerned about stacks that use a
    full-fledged mbuf structure and copy the data - their rates will be too low
    and they might as well reject the option.
    
    Julo
    
    "David Peterson" <dap@cisco.com> on 05/01/2001 23:40:07
    
    Please respond to "David Peterson" <dap@cisco.com>
    
    To:   "Matt Wakeley" <matt_wakeley@agilent.com>, "IPS Reflector"
          <ips@ece.cmu.edu>
    cc:
    Subject:  RE: new iSCSI draft - 02.txt
    
    
    
    
    The problem is: at that layer there is simply not a byte stream. The data
    is contained in socket buffers which are most likely mbuf clusters for most
    implementations. To "simply insert a few extra bytes" requires mbuf
    manipulation.
    Mbuf manipulation can processing intensive. Depending on how the mbuf data
    is
    packaged a small DMA operation may occur for these few extra bytes also.
    Dave
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Matt Wakeley
    Sent: Wednesday, January 03, 2001 7:21 PM
    To: IPS Reflector
    Subject: Re: new iSCSI draft - 02.txt
    
    
    David Peterson wrote:
    >
    > I believe there was agreement to remove the Urgent-Pointer framing
    mechanism
    > but don't recall any agreement to replace it with an in-stream marker.
    For
    a
    > software implementation it would be hard to support this type of framing
    > mechanism. I believe a TCP option indicating the message boundry or a
    > fixed-length PDU at a granularity to minimize overhead are much better
    > solutions and are workable for both software and hardware
    implementations.
    I
    > have not seen an agenda but I would hope this issue would be discussed at
    > the upcoming meeting in Orlando.
    > Dave
    
    What is so difficult for software to insert a few extra bytes in the byte
    stream?  It's simply a layering problem:
    
    iSCSI layer <-> marker layer <-> TCP
    
    Normally, the marker layer simply transfers the bytes from the iSCSI layer
    to
    the TCP. Every X number of bytes, the marker layer inserts the marker into
    the
    byte stream.
    
    Since your software will probably not benefit from the receipt of the
    markers,
    it would negotiate not to receive the markers.  It would only send markers
    *IF* the remote node requested them to be sent.
    
    -Matt Wakeley
    Agilent Technologies
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:57 2001
6315 messages in chronological order