Re: ISCSI: Urgent Flag requirement violates TCP.

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

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