Re: [Ipoverib] Comments on IPoIB Connected Mode Connection Establ ishment

Vivek Kashyap <kashyapv@us.ibm.com> Sat, 20 August 2005 17:11 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6WsB-0001c7-T3; Sat, 20 Aug 2005 13:11:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ws8-0001c2-IO for ipoverib@megatron.ietf.org; Sat, 20 Aug 2005 13:11:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00015 for <ipoverib@ietf.org>; Sat, 20 Aug 2005 13:11:05 -0400 (EDT)
Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6XSJ-0001Hn-MO for ipoverib@ietf.org; Sat, 20 Aug 2005 13:48:33 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7KHAuwh802674 for <ipoverib@ietf.org>; Sat, 20 Aug 2005 13:10:56 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7KHATeF476658 for <ipoverib@ietf.org>; Sat, 20 Aug 2005 11:10:29 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7KHAta6017029 for <ipoverib@ietf.org>; Sat, 20 Aug 2005 11:10:55 -0600
Received: from sig-9-65-23-100.mts.ibm.com (sig-9-65-23-100.mts.ibm.com [9.65.23.100]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7KHAsBf017024; Sat, 20 Aug 2005 11:10:54 -0600
Date: Sat, 20 Aug 2005 10:02:59 -0700
From: Vivek Kashyap <kashyapv@us.ibm.com>
X-X-Sender: kashyapv@localhost.localdomain
To: Jay Rosser <jay.rosser@hp.com>
Subject: Re: [Ipoverib] Comments on IPoIB Connected Mode Connection Establ ishment
In-Reply-To: <4304BED3.8010607@hp.com>
Message-ID: <Pine.LNX.4.62.0508201001150.4324@localhost.localdomain>
References: <506C3D7B14CDD411A52C00025558DED608749581@mtlex01.yok.mtl.com> <Pine.LNX.4.62.0508172327090.4324@localhost.localdomain> <4304BED3.8010607@hp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: Dror Goldenberg <gdror@mellanox.co.il>, IPoverIB <ipoverib@ietf.org>
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipoverib@ietf.org>
List-Help: <mailto:ipoverib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=subscribe>
Sender: ipoverib-bounces@ietf.org
Errors-To: ipoverib-bounces@ietf.org

On Thu, 18 Aug 2005, Jay Rosser wrote:

> Comment inline.
>
>> On Wed, 17 Aug 2005, Dror Goldenberg wrote:
>> 
>>> 
>>> 
>>>> From: Vivek Kashyap [mailto:kashyapv@us.ibm.com]
>>>> Sent: Monday, August 15, 2005 9:41 AM
>>>> 
>>>> On Wed, 10 Aug 2005, Dror Goldenberg wrote:
>>>> 
>>>>> Reviewing the ipoib-cm draft
>>>>> 
>>>> (http://www1.ietf.org/mail-archive/web/ipoverib/current/msg01372.html
>>>> 
>>>>> 
>>>> <http://www1.ietf.org/mail-archive/web/ipoverib/current/msg013
>>> 
>>> 72.html>
>>> 
>>>>> ) I have three comments about the connection establishment of
>>>>> IPoIB-CM.
>>>>> 
>>>>> (1) Service ID Reserved Bits
>>>>> 
>>>>> Section 3.3. defines the Service-ID as having reserved bits which must
>>>>> be transmitted as zeroes and ignored on receive.
>>>>> It doesn't sound right to ignore those bits on the receive  side.
>>>> 
>>> Ignoring
>>> 
>>>>> those bits on
>>>>> receive essentially means that the IPoIB-CM has to listen on a range of
>>>>> service IDs.
>>>>> I believe that it's better to define a service ID without  reserved bits
>>>> 
>>> such
>>> 
>>>>> that the
>>>>> passive side listens on a single service ID.
>>>>> For example, service IDs defined for SDP, don't have any reserved bits.
>>>> 
>>>> 
>>>> Is it not possible to mask the bits marked as reserved (or
>>>> unused)? The draft requires that the reserved bits must be
>>>> zeroes on send. If it is a limitation
>>>> of the connection manager that it cannot mask the bits and
>>>> will have to listen to the 'range' then I agree that the
>>>> service-ID will have to be specified
>>>> received as zeroes instead of ignoring them.
>>>> 
>>> 
>>> The CM interface is not defined in the IB spec, it is therefore
>>> implementation
>>> dependent. My understanding is that in OpenIB, the Linux CM is capable of
>>> masking the Service ID, but the Windows CM is not. I personally think that
>>> we should define those reserved as zero in send and receive, unless we
>>> can come up with an example of how future extension can leverage
>>> this feature.
>> 
>> 
>> ok, we might have to therefore check for zeros. Does anyone have
>> experience with  Solaris, HP/UX, other CM's?
>
> The HP-UX CM does not currently support masking ServiceIDs and thus cannot 
> support reserved bits in the UC IPoIB ServiceID.
>
> Jay

ok. I'll update the text.

Vivek

>
> <snip>
>
>
> -- 
> jay.rosser@hp.com 408-447-3175
>
>
>
>

_______________________________________________
IPoverIB mailing list
IPoverIB@ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib