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

Tzachi Dar tzachid at mellanox.co.il
Thu Sep 24 03:38:32 PDT 2009


I have applied the patch with Sean changes (2466), but one:
The AV that is used to send the lap message is not the primary one, but
the new loaded alternate path.
 
I still need to understand how to use the primary path in this scenario.
 
Since I'm working on a urgent project I don't have the time to do that
right now.
Since the old code didn't work at all, I have continued with this
approach that works for WSD, and opened bugzila:
 
https://bugs.openfabrics.org/show_bug.cgi?id=1751
 
Thanks
Tzachi


________________________________

	From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Tzachi Dar
	Sent: Wednesday, September 23, 2009 11:23 PM
	To: Sean Hefty; ofw at lists.openfabrics.org
	Subject: [ofw] RE: patch: Support APM on IBAL code
	
	

	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/20090924/f26a4620/attachment.html>


More information about the ofw mailing list