[ofw] RE: patch: Support APM on IBAL code

Sean Hefty sean.hefty at intel.com
Wed Sep 23 11:03:12 PDT 2009


Is there any way to generate the patches, so we can see the function name that
the changes belong to?

>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.

>
>+
>+//????????????

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?





More information about the ofw mailing list