On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote: > We are talking about two things here. The PKey in the BTH and the > PKey in the CM REQ payload. They differ. > > I am out of office, but if my memory serves me correct, the PKey in > the BTH in the MAD packet will be the default PKey. Further, we have > per IBTA: This sounds like a Linux bug. Linux does not do a PR to get a reversible path dedicated to the GMP, so it always uses the data flow path, thus the GMP path paramenters and those in the REQ should always exactly match. Where is Linux setting the BTH.PKey and how did it choose to use the default pkey? Lets fix that at least for sure. Once that is fixed the rest of the series makes no sense since a REQ with invalid PKey will never arrive. However... This series seems inconsistent with the spec. IIRC the spec doesn't say if a full or limited pkey should be placed in the REQ (Hal?). It is designed so that the requestor can get a single reversible path and put that results into the REQ without additional processing, however the PR returns only one PKey and again, itis not really specified if it should be the full or limited pkey (Hal?). Basically this means that any pkey in the REQ could randomly be the full or limited value, and that in-of-itself has not bearing on the connection. So it is quite wrong to insist that the pkey be limited or full when processing the REQ. The end port is expected to match against the local table. The real answer to your trap problem is to fix the SM to not create paths that are non-functional, that is just flat out broken SM behavior. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
