Re: ISCSI: Why the use of the Urgent Pointer

[ronald lee <ronald.c.lee@sun.com>]

Matt Wakeley wrote:
> 
> Look, this whole discussion comes down to a simple question.  Do you want
> iSCSI to succeed as an enterprise storage solution or not?  The intention of
> the urgent pointer is to help meet the requirements specified in the iSCSI
> Requirements document.
> 
> If we review the iSCSI Requirements document it requires:
> 
> - Low CPU utilization, equal to or better than current technology.
> 
> This requirement cannot be met using off the shelf TCP/IP stacks running in
> the OS, especially at 10Gbps. iSCSI solutions will have to be implemented in
> adapters that handle the transfer of data, similar to Fibre Channel adapters.
> Otherwise, iSCSI will eat up all the CPU cycles performing TCP/IP processing,
> and FC will blow iSCSI away.

I agree that packet processing needs to be offloaded but this might not
be
always true.  Some implementations might not care if you dedicate a
server to
a specific application such as mirroring data across LAN/WAN and you
don't use
this server for anything else.  This is up to the user.

> 
> - Cost competitive with alternative storage network technologies.
> 
> In order for iSCSI to succeed it must be able to be cost competitive with
> other solutions (10Gig Fibre Channel, etc).  This means that it must be
> implementable without putting gobs of (costly) memory on the adapter cards.

I think same problems might exist in fibre channel if hardware loses
data and
even fibre channel has to resend the data.  Its a matter of high
reliable is
the connection and the devices in the connection.  Even TCP/IP networks
can
be reliable if it was dedicated to serving I/Os only and all paths along
the
way was reserved or leased lines.  

> In order to avoid this memory requirement in the presence of lost frames, the
> adapter will either have to place data in host memory were it belongs
> *requiring a framing mechanism* or throw it away.  Fibre Channel adapters
> today are able to operate in this manner today without a lot of memory because
> they can place data that arrives out of order directly where it belongs in
> host memory [because framing is provided].

I think it is good to have framing, but not at the expense of all the
software
and testing that is involved in making this work.  If someone wants run
at
10 GBit rates across WAN, they might need a little more help than just
framing.
Also, having 100Mbytes of memory is not such a big deal these days with
the
cost of memory coming down.  Instead of having one data connection, if
you had
100s of connections, the other connections can still operate since they
did
not lose any packets. 

> 
> The urgent pointer mechanism in the current draft provides the framing
> mechanism so that data can be placed properly in the presence of dropped
> frames.

Sounds like this will help in terms of saving the memory required on the
adapters since the command that has the lost frame still needs to wait
for
that lost frame.

I think overall, if you are losing packets in the network regularly,
doing this
will not help performance because TCP resends will slow you down
anyways.  If
the network is not losing packets, then out of order segments will just
be
momentary.


> 
> Matt Wakeley
> Agilent Technologies