SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: ISCSI: Urgent Flag requirement violates TCP.



    Glen,
    I can confirm that when it comes to implementations that will be found on
    most Server Class Systems, the need for a TCP/IP implementation, which is
    off-loaded to an HBA (NIC), is desperately needed.  It is needed, in order
    for the Server to have a Storage Networking solution, using iSCSI, that is
    comparable (in its CPU load) to a FC HBA.  We have tested many "Normal"
    Gigabit NICs, with "normal" Server TCP/IP Stacks, and depending on the NIC,
    have found the CPU time needed (for max line speed) to be in the range of
    50%- 70% in most cases.  10 Gigabit just can not be done without a HW ASIC
    approach. (Note: there are some newer NICs that have acceleration features,
    and they improve the above numbers, somewhat, but not nearly enough.)
    
    This is the reason that Many different NIC vendors have committed to
    produce TCP/IP offload implementations --, including, in some cases -- even
    iSCSI itself being off-loaded.  Most folks believe that these HW
    implementations will provide as low a CPU impact as does a Fibre Channel
    HBA.
    
    In spite of all the facts above,  I believe that many non Server Class
    Systems (Desktop & Laptops) will use existing TCP/IP stacks and 100 MHz
    Links.  In many situations this provides very adequate response for these
    class systems (& uses about 5% to 7% of the CPU).  We also see a number of
    customers updating their Office wiring cabinets to support 10/100/1000
    Ethernet Switches that use standard CAT 5 cables (which are currently
    installed in many/most offices).  It is expected that over time, these
    Desktop systems will upgrade to 1000baseT adapters, and will enable the
    Desktop units to obtain more then 10 MByte/sec while increasing, of course,
    the CPU utilization of the Desktop.  The latter is not really considered a
    problem, since it will tend to balance out with the need of the individual
    Desktop for I/O versus its processor requirements. (Note: you can not
    reasonably say that same thing for Servers since they need to handle the
    needs of many Desktops.)
    
    So what this all means is: Matt is stating (rightly or wrongly) that folks
    can make their integrated NIC adapters much more efficient if the Urgent
    pointer is used by everyone.  He is NOT saying that it is useful to the SW
    stack implementations, but he believes that it does not hurt them.
    
    There are some folks that believe that we need to give these integrated HW
    implementations every chance possible to be  highly efficient, especially
    since 10Gigabit and beyond are just around the corner.  Some even say that
    the future of iSCSI actually depend on the efficient handling of the
    Gigabit links.
    
    OK, I just wanted to separate the different implementation needs so that
    the team could understand what folks like Matt are talking about.  And what
    they are not talking about.
    Its, of course, up to you folks to determine if his approach is valid.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403
    Internet address: hufferd@us.ibm.com
    
    
    Matt Wakeley <matt_wakeley@agilent.com>@ece.cmu.edu on 11/07/2000 11:41:52
    PM
    
    Please respond to Matt Wakeley <matt_wakeley@agilent.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Glen Turner <glen.turner@aarnet.edu.au>, ips@ece.cmu.edu
    cc:
    Subject:  Re: ISCSI: Urgent Flag requirement violates TCP.
    
    
    
    Glen Turner wrote:
    
    > Matt Wakeley wrote:
    > >
    > > > But when I look at the socket API for UNIX I can't see how
    > > > a receiver can use Urgent data create a synchronisation point
    > > > within a TCP stream.
    > >
    > > For a strictly software implementation, the urgent pointer provides no
    benefit at all.
    > > This framing mechanism is to help special TCP/iSCSI accelerated
    implementations, not
    > > iSCSI implemented using generic off the self TCP stacks.
    > >
    > > Sorry I forgot to mention that...
    >
    > Hi Matt,
    >
    > Actually, now I'm feeling even more confused.  I am assuming
    > my cold is making me slow, so I apologise for that.
    >
    > Won't the client (the machine using the disk) almost always
    > be a general purpose computer, and thus using an "off the shelf"
    > TCP stack?
    
    Nope.  Machines today using "off the shelf" stacks utilizing 1Gbps ethernet
    max out the CPU
    running the TCP/IP stack, with no processing power left over for doing any
    work.  Machines
    will not be able to fully utilize the new 10Gbps links if the TCP/IP
    processing is not
    offloaded out of the main kernel.
    
    -Matt Wakeley
    Agilent Technologies
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:27 2001
6315 messages in chronological order