[openib-general] [PATCH][iWARP] Added provider CMverbsandqueryprovider methods

[Tom Tucker]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of Sean Hefty
> Sent: Friday, August 26, 2005 12:34 AM
> To: 'Bob Sharp'; Caitlin Bestler; openib-general at openib.org
> Subject: RE: [openib-general] [PATCH][iWARP] Added provider 
> CMverbsandqueryprovider methods
> 
> >>From NetEffect's perspective, the per device approach is simple to
> >implement and I do not see it as an Ammasso specific 
> approach.  As Caitlin
> >described, existing code needs to be reorganized but this 
> aspect of our port
> >is not a major effort.
> 
> I agree that connection setup code could be duplicated in all 
> iWarp drivers to
> make such an interface work, but that doesn't necessarily 
> make it the best
> approach.  Personally, I would rather see a single iWarp 
> connection manager
> establish the connections, and then hand those as the LLP 
> handle to the modify
> QP verb.
> 
> Based on comments, the iWarp vendors would prefer the host 
> TCP stack establish
> connections.  If this is the case, then why isn't having a 
> single iWarp CM that
> resides above verbs preferred to duplicating that 
> functionality in each driver?
> 
> To me, this does sound like an Ammasso specific approach, in that they
> implemented TCP connections in hardware.  Responses from 
> NetEffect and Broadcom
> mentioned software solutions.

I believe that what you are advocating is having a mini-TCP-stack 
in Linux. This mini-TCP-stack knows how to establish connections
which are then passed down to the adpater.  This mini-stack would 
comprise the iWARP side of a unified connection manager. 

This is all fine and good, but for the fact
that not all adapters work this way. In fact, to date, *MOST* 
TOE engines including Chelsio, Adaptec, Emulex, and others
establish connections themselves. Admittedly, I don't know how
the Broadcom and NetEffect RDMA adapters plan on doing it.

That said, there needs to be a device attribute that indicates 
whether the host establishes the connection on the adapter 
or takes existing connection state from the host. If the adapter 
establishes the connection, it must export functions to do so. I 
proposed yesterday that we have a separate structure for this 
purpose that is hung off the ib_device. This structure will be 
present and populated for adapters that establish connections 
themselves.

As far as the host-mini-TCP stack goes...I find it almost impossible 
to believe that it has a better chance of getting pushed upstream
than does host-stack integration. We should clearly articulate the
host-adapter split stack model, why it is necessary for RDMA devices,
and attempt to convince the netdev/stack community that this is the
right thing to do. A mini-TCP stack in the host is a separate piece
of logic that duplicates existing functionality that serves no other
purpose than to delay an inevitable argument about upstream integration.


> 
> - Sean
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>