[openib-general] [PATCH][iWARP] Added provider CM verbsandquery provider methods

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of 
> glebn at voltaire.com
> Sent: Tuesday, August 30, 2005 12:38 AM
> To: Tom Tucker
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] [PATCH][iWARP] Added provider 
> CM verbsandquery provider methods
> 
> I don't want to move flamewar from netdev to this list...
> 
> On Mon, Aug 29, 2005 at 12:46:47PM -0400, Tom Tucker wrote:
> > 
> > >From my reading of the thread, there is resistence to
> > TOE in general. The patch is just the messenger. The principle 
> > opponent is Dave Miller who strongly believes that stateless 
> > acceleration such as TSO (TCP Segmentation Offload) 
> suffices for all 
> > needs. Ironically, this requires a much higher level of stack 
> > integration than TOE does.
> I think there is no irony in this. From my understanding of 
> the thread the higher level of integration is what Dave is 
> striving to. This will allow linux users to have latest and 
> greatest most RFC compliant and secure TCP stack and at the 
> same time enjoy 10Gb performance. He doesn't want to have two 
> different TCP implementation on the same machine (or more if 
> you install several different TOE cards).
> 
> 
> 
> > 
> > TOE for the purposes of RDMA may have more legs within the 
> community, 
> > however, this has yet to be tested.
> Is it possible to implement RDMA semantics using linux native 
> TCP stack (with hardware assistance of cause)? Just asking.
> 
> 

It is possible to implement RDMA on the host processor. But
it will not match the performance of hardware. The difference
will be substantial at 10G. If someobody could build a software
only solution that performed at 10G they would have done so.
Having zero manufacturing cost would give them quite a 
competitive edge over solutions that required hardware.

The need for offload has more to do with memory bandwidth
than raw processing power. The data bandwidth required to
support look-up of large data structures and for placement
of the raw payload nearly consumes the bus bandwidth when
operating at peak wire speeds. If you make that worse by
moving the raw packets over the wire, and *then* copying
them to a final location (a second memory move) *and*
additional memory touches for accessing control structures...

Well, it simply does not work. And no amount of wishful
thinking will make it work.

Customers do not seek hardware offload out of any great
desire to turn their money over to hardware vendors. They
pay a premimum for offloading NICs because it solves their
problems.