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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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