[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