<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: IPoIB CM connectivity issue.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2><BR>
> > In case if connection initiated by remote node(B), OFED node(A)<BR>
> > accepts connection and then sends it's own connect request to the same<BR>
> > node(B) using different RC QP!<BR>
<BR>
> Yes, in the Linux implementation of IPoIB CM, each QP is used for<BR>
> traffic in only a single direction. This simplifies things quite a bit<BR>
> in the implementation, and as far as I know is a fully compliant thing<BR>
> to do.<BR>
<BR>
In second case (when OFED is CREQ initiator) only one RC QP was used to establish a connection and<BR>
apparently bidirectional traffic was capable to go through that one QP.<BR>
<BR>
> > It looks like violation of RFC4755 convention to send unicast data over<BR>
> > connected QP.<BR>
<BR>
> I assume you mean sending ARP replies. Yes, you are correct. I never<BR>
> noticed before but RFC 4755 does say:<BR>
<BR>
> Additionally, all address resolution responses (ARP or Neighbor<BR>
> Discovery) MUST always be encapsulated in a UD mode packet.<BR>
<BR>
Yes, you are right. Please discard my note regarding ARP reply.<BR>
<BR>
Thanks,<BR>
Alex</FONT>
</P>
</BODY>
</HTML>