<br><font size=2 face="sans-serif">Hello Michael,</font>
<br>
<br><font size=2 face="sans-serif">Yes, the code seems to get complex with
lots of small changes spread across all over the recieve side. Plus </font>
<br><font size=2 face="sans-serif">special cassing them with #ifdef makes
it look a little messy. It is unlikely I can get this out by Feb 1st.</font>
<br>
<br><font size=2 face="sans-serif">As I was working through this I noticed
a few things and here are my observations:</font>
<br>
<br><font size=2 face="sans-serif">-ipoib_cm_modify_rx_rts() does not actually
transition the passive side qp to RTS state and remains in the</font>
<br><font size=2 face="sans-serif">RTR state. However, the active side
qp does transition to RTS.</font>
<br>
<br><font size=2 face="sans-serif">-One artifact of the current send side
implemantation is that for every message we create a new set of tx qps.</font>
<br><font size=2 face="sans-serif">So, if one were to use IB for the cluster
heartbeat mechanism as an example, then for every heartbeat we</font>
<br><font size=2 face="sans-serif">end up creating an ipoib_cm_tx structure
and initiating a set of CM exchanges.  This might consume a lot of</font>
<br><font size=2 face="sans-serif"> resources (even on an "idle"
system). Changing this has a potential performance upside.</font>
<br>
<br><font size=2 face="sans-serif">Pradeep</font>
<br><font size=2 face="sans-serif">pradeep@us.ibm.com </font>
<br>
<br><tt><font size=2>"Michael S. Tsirkin" <mst@mellanox.co.il>
wrote on 01/25/2007 11:41:28 PM:<br>
<br>
> > Quoting Pradeep Satyanarayana <pradeep@us.ibm.com>:<br>
> > Subject: IPOIB CM with Non SRQ support<br>
> > <br>
> > <br>
> > Michael, <br>
> > <br>
> > I am working on a prototype based on your IPOIB CM patch to <br>
> incorporate support for Non SRQ  as well. IPOIB CM was planned
to be<br>
> in OFED 1.2 if I remember correctly. If I were to submit a patch for<br>
> non SRQ support, what would be the cut off date to make it<br>
> > into OFED 1.2? <br>
> <br>
> I think it must be ready for merge by feature freeze on Feb 1st, but
at this<br>
> stage it really needs to be a small patch. I can't commit to merging
it<br>
> before I see it.<br>
> <br>
> I have to warn you that I thought about this problem, and unfortunately<br>
> I do not see a way to implement it in a robust fashion without complicating<br>
> the code significantly. In this case, you'll just might have to maintain
it<br>
> as a separate patch until the code lands upstream, and propose as
a separate<br>
> improvement later.<br>
> <br>
> -- <br>
> MST<br>
</font></tt>