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

[Tzachi Dar]

It seems that one change in my code is causing build break, and I have
there for reverted this part on 2467.
 
It seems that the function al_cep_pre_req is now replaced with
kal_cep_pre_req witch doesn't have the IB QP, as part of it.
 
In order to allow me to return this code, it seems that the best
solution is to add a new member to the struct iba_cm_req: iq_qp_hqndle_t
h_qp.
 
Are there any objections to this? (In other words, am I breaking some
kind of abstraction here?)
 
Thanks
Tzachi


________________________________

	From: Tzachi Dar 
	Sent: Thursday, September 24, 2009 1:39 PM
	To: Tzachi Dar; Sean Hefty; ofw at lists.openfabrics.org
	Subject: RE: [ofw] RE: patch: Support APM on IBAL code
	
	
	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/f55a5248/attachment.html>