[ofa-general] Re: IPoIB CM connectivity issue.

[Roland Dreier]

 > In second case (when OFED is CREQ initiator) only one RC QP was used
 > to establish a connection and apparently bidirectional traffic was
 > capable to go through that one QP.

Yes, at least in the case where you have an SRQ-capable adapter, it
doesn't really matter which QP has incoming traffic.  However, it was
much simpler in the IPoIB implementation to simply open a QP to send
traffic rather than searching through all passive connections for a
connection to the same peer.

Is this behavior causing problems for you?

 > > I assume you mean sending ARP replies.  Yes, you are correct.  I never
 > > noticed before but RFC 4755 does say:

 > >    Additionally, all address resolution responses (ARP or Neighbor
 > >    Discovery) MUST always be encapsulated in a UD mode packet.

 > Yes, you are right. Please discard my note regarding ARP reply.

Not sure what you mean -- if Linux is sending ARP replies on a connected
QP, then that is not allowed according to the RFC.

However, looking at this quote again I see that the RFC's requirement
rather unfortunately includes neighbour discovery too.  It's not *too*
bad to look at the ethertype in the IPoIB pseudo-header to check for an
ARP packet, but sending all neighbour discovery messages seems very ugly
-- even just sending all ICMP6 messages via UD wouldn't be very nice to
implement, and it would eg break ping6 with large messages, so we would
have to look deep deep into packets to see which were ND messages.

I wonder what the rationale behind that part of the RFC was?

 - R.