Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc.

["David R. Cheriton" <cheriton@cisco.com>]

Alan,

Given you are concerned about Appletalk and PCI, perhaps we just
need to agree you are addressing a different performance level of
storage system.  I see no reason for hardware support at Appletalk
and PCI speeds either.  The RDMA option, even implemented in
a hardware NIC, would not preclude software processing of Appletalk
or anything else.

  I think it would be only fair for this group to expect you to
provide a more fully worked out design and evaluation of your
proposed NIC if this is really to be taken as a serious alternative
to an RDMA option.  I for one dont find it a competitive design
(it is also one that was previously considered.)

Regarding the complexity of TCP processing in hardware, people are 
doing this, so I regard this as a done deal.  (I'd hate
to be a high-speed NIC vendor that cant do this.)
The only issue is how to handle the next level of 
protocols that have high performance requirements, i.e. storage.
Also, NICs with hardware enhancements for protocol support,
such as the Intel Gigabit Ethernet NIC have been very successful
both in performance and market.  So, expect more there.

Finally, the RDMA option is targeted to allow use of standard
 Internet protocols for SANs in place of  specialized protocols
and networks such as  FibreChannel, especially for non-local 
access.
I.e. an extra option rather than an extra protocol stack and network.
I hope the discussion can recognize that broader issue in considering
alternatives and the general need for the RDMA option.
I.e. can SCSI over TCP really compete with FC without the RDMA option?
(In this sense, the subject line should have put SCSI first.)

DRC

At 10:41 PM 2/27/00 +0000, Alan Cox wrote:
>> it seems like a cost issue of providing the above hardware resources
>> vs. providing a NIC chip that can RDMA.  
>
>or a NIC chip that has more memory on the chip and sends you the header then
>you asynchronously give a DMA location for the rest of the buffer.
>
>You've now got rid of RDMA, instead your little bit of extra silicon is 
>generic, and will work with stuff like appletalk even. What does the
>extra RAM and PCI glue cost you - probably not a lot.
>
>That is why I prefer software solutions
>
>> >It might also be fragmented of course.
>> What you need to do >>in the common case<< before processing the RDMA
>> option is relatively simple and a very small portion of the
>> overall protocol state machines, so I presume your comment is
>> asking for more careful wording? Or do you really disagree with the
>> fundamental point?
>
>Yes
>
>The sequence of operations you must execute is complex. 
>
>You have to
>
>Check the packet is long enough
>Check the header is IPv4
>Check the IPV4 IHL is valid
>Check the protocol field
>Check the source/dest addresses are legal
>Work out if dest is for us or another node
>Perform IP fragmentation (checks at least cannot be deferred defrag can)
>Walk the IP options (I guess you could defer this)
>Get the tcp header
>Check the tcp header lengths are legal and fit the packet length
>Check the tcp ports to figure out the socket
>Parse the tcp options 
>Check the RDMA identifier, arbitarily aligned of course
>Check the RDMA identifier, port and addresses match
>Perform sequence space checks
>
>Then you can deliver the packet.
>
>Alan
>
>
>
>