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

[Tzachi Dar]

SB

Thanks
Tzachi

-----Original Message-----
From: Sean Hefty [mailto:sean.hefty at intel.com]
Sent: Wednesday, September 23, 2009 9:03 PM
To: Tzachi Dar; ofw at lists.openfabrics.org
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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20090923/bd6d080f/attachment.html>