RE: Some Questions on the IPoIB - Connected Mode Draft

Hal,
 
Ooops, you're right. I was reading it on my email with font that didn't have
fixed width....
So, I agree with what you say, it'll be nice to have QPN not crossing a 32
bit boundary.
 
-Dror

-----Original Message-----
From: Hal Rosenstock [mailto:[email protected]]
Sent: Monday, July 26, 2004 1:59 PM
To: Dror Goldenberg
Cc: [email protected]
Subject: Re: [Ipoverib] Some Questions on the IPoIB - Connected Mode Draft


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  <mailto:[email protected]> Goldenberg 
To: Hal  <mailto:[email protected]> Rosenstock ; [email protected]
<mailto:[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.t
xt>
http://www.ietf.org/internet-drafts/draft-kashyap-ipoib-connected-mode-02.tx
t) 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 this
contradicts the earlier statement. It seems like the UD QP for connected
mode is only required when the same partition and scope
are 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 subnet
includes 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 peer
using 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 which
issued 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

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