SB Thanks Tzachi
-----Original Message----- From: Sean Hefty [mailto:[email protected]] Sent: Wednesday, September 23, 2009 9:03 PM To: Tzachi Dar; [email protected] Subject: RE: patch: Support APM on IBAL code Is there any way to generate the patches, so we can see the function name that the changes belong to? I guess there is, but if someone can tell me how to do it, I'll be happy to do it next time. >2) when sending LAP, there are two parameters for the path record: one >is the src port that is based on the av that I'm now loading. The >second is the dest_lid which is based on the value that we have on our >p_cep->av[p_cep- >>idx_primary]. I'm not sure if this is the design, or is this just a >>bug and >the dest_lid should also be taken from the av that is currently being supplied. I'm not familiar enough with the code to follow this closely. When sending a LAP, I would expect the current primary path to be used. This is probably what happens. The path used is the alternate path that was loaded one time before. There have been a migration so this is now the primary path. > >+ >+//???????????? please remove >@@ -4731,6 +4731,12 @@ > break; > } > >+ if(p_cm_req->h_qp->type == IB_QPT_RELIABLE_CONN) { >+ ((al_conn_qp_t *)(p_cm_req->h_qp))->cid = cid; } Why limit setting this to RC QPs, versus all QPs? >@@ -5424,7 +5430,7 @@ > > __format_mad_hdr( p_mad->p_mad_buf, p_cep, CM_LAP_ATTR_ID ); > >- __format_mad_av( p_mad, &p_cep->av[p_cep->idx_primary] ); >+ __format_mad_av( p_mad, &p_cep->av[((p_cep->idx_primary + 1) & 0x1)] >+ ); Does this end up sending the LAP on the primary path, or the new alternate path? I'll double check this, Very likely that now the new path is used. I'll look at making sure that the current primary path is indeed used.
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
