|
[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 |