Re: Some Questions on the IPoIB - Connected Mode Draft

"Hal Rosenstock" <[email protected]> Mon, 26 Jul 2004 06:59:10 -0400

Newsgroups	gmane.ietf.ipoib
Message-ID	<[email protected]>

Hi Dror,

On #4, it looks to me like the service ID currently is :
The Service-IDs used by IPoIB will be in the format:

+--------+--------+--------+--------+-------+-------+--------+-------+
|00000001| Type |Reserved| QPN | Reserved |
+--------+--------+--------+--------+-------+-------+--------+-------+ byte 0 = IETF = 0x01
byte 1 = Type = 0x00
byte 2 = Rsvd = 0x00
byte 3-5 = QPN[23:0]
byte 6-7 = Rsvd = 0x0000

as the first Rsvd field is a single byte and the second one two bytes.

It would be better the way you state:

+--------+--------+--------+-------+-------+--------+-------+--------+
|00000001| Type | Reserved | QPN |Reserved|
+--------+--------+--------+-------+-------+--------+-------+--------+or

+--------+--------+--------+-------+-------+--------+-------+--------+
|00000001| Type | Reserved | QPN |
+--------+--------+--------+-------+-------+--------+-------+--------+
-- Hal
----- Original Message -----
From: Dror Goldenberg
To: Hal Rosenstock ; [email protected]
Sent: Sunday, July 25, 2004 5:33 PM
Subject: RE: [Ipoverib] Some Questions on the IPoIB - Connected Mode Draft

Hi Hal,

I can try to address items 4 and 5:

4. QPN crossing 32 bit boundary - I don't think that this is the case. If you count
bytes from the MSB down to the LSB, then:
byte 0 = IETF = 0x01
byte 1 = Type = 0x00
byte 2-3 = Rsvd = 0x0000
----- 32 bit boundary ---
byte 4-6 = QPN[23:0]
byte 7 = Rsvd = 0x00
----- 32 bit boundary ---

5. Rejection of REQ in case of non matching MTU - I think that it may have to do with
the fact that by the time you send the REQ, in some implementations you
already allocated your buffers and posted them on the WQ (while the QP
was in INIT state). So, if you don't reject and thus force the QP to flush all these
WQEs, you may end up doing some complicated buffer management operations.
E.g. getting rid of the old posted buffers, allocating new ones and reposting them
once the old buffers complete.
Note that I am really not sure about this one...

-Dror

-----Original Message-----
From: Hal Rosenstock [mailto:[email protected]]
Sent: Sunday, July 25, 2004 12:14 AM
To: [email protected]
Subject: [Ipoverib] Some Questions on the IPoIB - Connected Mode Draft

Hi,

I just finished reading the "IPoIB connected mode" I-D (http://www.ietf.org/internet-drafts/draft-kashyap-ipoib-connected-mode-02.txt) and have some questions:

1. In 2.2 Outline of Address Resolution, it is stated that:
Every IPoIB-CM interface MUST have two QPs associated with it:
1) A connected mode QP
2) An unreliable datagram mode QP
I'm a little confused by the description of the first QP. Is this a really a UD QP used for connected mode address resolution (when the interface is not in the same scope and partition as the UD one) ? It is also later stated (in 3.0 Address Resolution) that IPoIB-CM can use the same UD QP as the one used by IPoIB-UD interface when they share the same partition and scope so it seems thiscontradicts the earlier statement. It seems like the UD QP for connected mode is only required when the same partition and scopeare not shared with the IPoIB-UD interface.2. In 3.1 Link Layer Address, it is stated that the RC and UC flags are mutually exclusive. Is this a requirement or more a configuration issue ? Is there something which would break with both flags on ? The only issue I see is if a IPoIB-CM subnetincludes some nodes supporting only RC and others only UC. That couldn't be mi!
xed. I suppose setting both opens the door for that to occur.3. In 3.2 IB Connection Setup, it is stated that the node SHOULD NOT attempt another connection to the remote peerusing the same service ID as for an already existing connection. Wouldn't that potentially be useful for support of QoS ?Is this a recommendation (SHOULD NOT) just to reduce the number of connections (and QPs) ? 4. In 3.3 Service ID, wouldn't it be better if the QPN didn't overlap a 32 bit boundary ?5. In 5.1 Per Connection MTU, why does the peer need to REJ the connection the the REQ desired MTU is not acceptable(and is more than the minimum MTU) ? Couldn't we REP with the "MTU granted" for that case ? The active side whichissued the REQ could always REJ the REP if it didn't like the "MTU granted".-- Hal!

------------------------------------------------------------------------------

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib