Re: ipoib-cm nits/clarifications

>- page 10, section 6.0 - what is the final MTU of a connection ? is it the
>minimum between
>   the two "receive MTU" , or is it hybrid - different MTU per half
>connection ?

Although there is really no reason to demand for a single MTU value
per connection as long as a sender never sends a message large than
the "Receive MTU" of the receiver, I'd expect most implementations
would want to choose one value for both directions for simplicity.
For that I'd suggest to take the min as the final MTU for both directions
so that the side that advertises a 32KB MTU doesn't need to post
32KB receive buffers and waste memory if the other side will never send
msgs larger than 16KB, for example.

>I think that the current model for multiple connections establishment
>between 
>two peers works well for 1 connection but is broken for more than one
>connection.
>Because of cases where CM packets are dropped or travel on different VLs,
>they 
>might get reordered on the way and observed in a different order than were
>originally
>sent. This breaks the current model which assumes that the REQs are sent and
>processed in order.

Isn't this a problem at the IB layer already, or this problem is introduced
by the 20byte comparison for the REQ crossing case?

I wish the connection setup can be kept as simple as possible, e.g.,
active-active as you've suggested. But that requires a common service-ID,
and the logical choice of using the P_Key takes away the flexbility of
allowing multiple IP subnets/IPoIB-UD QPs to occupy the same partition...

Jerry