[openib-general] round 2 - proposal for socket basedconnection model

[Steve Wise]

Why does an application care whether the remote implementation supports 
ZB?  Whether memory regions can be described with zero based rkeys or 
not doesn't matter on an end-to-end level.  Its only a local issue.  So 
ZB shouldn't be there IMO.



----- Original Message ----- 
From: "Tom Tucker" <tom at opengridcomputing.com>
To: "Kanevsky, Arkady" <Arkady.Kanevsky at netapp.com>
Cc: <swg at infinibandta.org>; <openib-general at openib.org>
Sent: Tuesday, October 25, 2005 4:55 PM
Subject: RE: [openib-general] round 2 - proposal for socket 
basedconnection model


> Arkady:
>
> I may actually have a constructive comment about the protocol (private
> data format). One thing I noticed is that *almost* everything in the
> private data header is available in the native iWARP protocol header
> except the ZB and SI bits.  If these bits become part of the canonical
> private data header, then does that require an iWARP transport to use
> the header too even though only two bits are useful?
>
> Sorry if this is a dumb question,
>
> Tom
>
> On Tue, 2005-10-25 at 16:40 -0500, Tom Tucker wrote:
>> Arkady:
>>
>> I don't think anyone disagrees with your goals. Unfortunately 
>> additional
>> requirements on the implementation were coupled with the 
>> specification
>> of the private data format (protocol). This peripheral discussion
>> derailed any attempt to discuss the protocol.
>>
>> Attempts to separate the protocol discussion from the implementation
>> failed. And so here we are...
>>
>>
>> On Tue, 2005-10-25 at 15:38 -0400, Kanevsky, Arkady wrote:
>> > 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
>> > >
>> > _______________________________________________
>> > 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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
>