On 10:11 Wed 09 Mar , Jason Gunthorpe wrote: > On Wed, Mar 09, 2011 at 05:47:44PM +0200, Alex Netes wrote: > > Hi Jason, > > > > On 17:29 Tue 01 Mar , Jason Gunthorpe wrote: > > > This value must match the portGUID, so it needs to vary on a per port > > > basis like portGUID and not simply reflect the value opensm acquired > > > during the sweep. > > > > > > Prior to this patch opensm returns the same value for localPortNum for > > > all ports on a HCA, now it returns the correct localPortNum for the > > > portGUID. > > > > > > Also fixes query matching in the same way > > > > > > Spec defines the SA NodeRecord.LocalPortNum field as the number of the link > > port which received this SMP (14.2.5.3). This definition doesn't make any > > sense when it comes to SA. > > I think the spec is pretty sound on this point. The SA is expected to > return SA queries for SMP records that match what is present in the > fabric if the requestor did the SMP query itself. The constraints IBA > places on a NodeInfo SMP query are such that localPortNum and > portGUID must *always* match. You cannot enter on port 1 and query the > NodeInfo for port 2 for a CA. >
You are right about this. There is no case I can think of, where PortGUID can be different than localPortNum, when it comes to CAs. However for switches there is no such coupling. For NodeInfo SMP localPortNum can be any port, but the portGUID remain the same. All I'm saying is that section 15.2.5.2 or 14.2.5.3 should be more clear about the definition of LocalPortNum field when it comes to SA. > So the current SA behavior of returning garbage for localPortNum > is essentially returning a NodeInfo that can never be returned by a > raw SMP query, which is clearly not aligned with the intent of the spec. > There is same definition for localPortNum in PortInfoRecord, however the correct localPortNum is retrieved. So I guess NodeInfoRecord could act same way you suggested. > I mispoke a bit in the commit message, opensm returns the localPortNum > it acquired during the sweep *for a random port*, eg it collects and > stores the NodeInfo for the first port it sees, then stores portGUID > and localPortNum seperately. When it generates the SA reply it > corretly replaces the port GUID but uses the random old > localPortNum. This is clearly incorrect. > > > I understand your motivation for the patch and the fact that current > > LocalPortNum query matching in the SM doesn't sound right. So maybe > > IBA spec fine tuning is needed, before applying the patch, so this > > field won't be open to free interpretations. > > I don't think there is really any free interpretation here. For > everything but a switch localPortNum must always reflect the port that > portGUID is associated with. This is is what is defined to happen when > the NodeRecord SMP is generated by the SMA, the SA must do the same. > > This causes real problems, without an accurate localPortNumber it is > impossible to associate the portGUID with a port number when doing SA > queries > What about using PortInfoRecord to get portGUID<->localPortNumber binding? One more minor thing, you defined port_num/match_port_num as unsigned int. I think it can be uint8_t, right? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
