[openib-general] round 2 - proposal for socket based connectionmodel

[Kanevsky, Arkady]

What are you trying to achieve?

I am trying to define an IB REQ protocol extension that
support IP connection 5-tuple exchange between connection
requestor and responder.
And define mapping between IP 5-tuple and IB entities.

That way ULP which was written to TCP/IP, UDP/IP, CSTP/IP (and so on)
can use RDMA transport without change.
To modify ULP to know that it runs on top of IB vs. iWARP
vs. (any other RDMA transport) is bad idea.
It is one thing to choose proper port to connect.
Completely different to ask ULP to parse private data
in transport specific way.

The same protocol must support both user level ULPs
and kernel level ULPs.
Arkady

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance                     phone: 781-768-5395
375 Totten Pond Rd.                  Fax: 781-895-1195
Waltham, MA 02451-2010          central phone: 781-768-5300
 


> -----Original Message-----
> From: Sean Hefty [mailto:mshefty at ichips.intel.com] 
> Sent: Tuesday, October 25, 2005 3:22 PM
> To: Kanevsky, Arkady
> Cc: Sean Hefty; openib-general at openib.org; swg at infinibandta.org
> Subject: Re: [openib-general] round 2 - proposal for socket 
> based connectionmodel
> 
> 
> Kanevsky, Arkady wrote:
> > Sean,
> > answers in-line.
> > Arkady
> 
> At this point, I'm just going to disagree with this approach 
> and move on with 
> the current implementation of the CMA.  What's needed is a 
> service that provides 
> IB connections using TCP/IP addressing.  I don't believe this 
> proposal meets 
> this goal.
> 
> To meet the requirement of connecting over IB using TCP/IP 
> addressing, I believe 
> that we need a service with a reserved service identifier or range of 
> identifiers, a mechanism for mapping between IP and IB 
> addresses, and a 
> mechanism for reversing the mapping.
> 
> I don't see where the proposal addresses the bulk of the work 
> that's required, 
> nor do I think that it will present an API to the user that 
> does not expose IB 
> related addressing (such as service IDs).
> 
> - Sean
>