On Thu, May 17, 2018 at 09:34:47AM +0300, Alex Rosenbaum wrote:
> On Thu, May 17, 2018 at 8:59 AM, Leon Romanovsky <leon@xxxxxxxxxx> wrote:
> > On Wed, May 16, 2018 at 12:27:22PM -0600, Jason Gunthorpe wrote:
> >> On Tue, May 08, 2018 at 05:25:09PM +0300, Leon Romanovsky wrote:
> >>
> >> > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> >> > index d84e6b6a8a56..2323a5624161 100644
> >> > +++ b/include/rdma/ib_verbs.h
> >> > @@ -455,6 +455,7 @@ enum ib_port_cap_flags {
> >> > IB_PORT_LINK_LATENCY_SUP = 1 << 24,
> >> > IB_PORT_CLIENT_REG_SUP = 1 << 25,
> >> > IB_PORT_IP_BASED_GIDS = 1 << 26,
> >> > + IB_PORT_GRH_REQUIRED = 1 << 27,
> >> > };
> >>
> >> Ahh.. What?
> >>
> >> This bitmap was supposed to be controlled by IBTA, it is
> >> PortInfo:CapabilityMask, and bit 26 and 27 are already defined by
> >> IBTA!
> >>
> >> So we can't just co-op them!!!
> >>
> >> Is this what all the crazy masking is about above??
> >>
> >> NAKitty nak nak..
> >>
> >> And someone needs to fix IB_PORT_IP_BASED_GIDS :( :(
> >>
> >> It overlaps with IsOtherLocalChangesNoticeSupported - not sure how to
> >> fix it. Sadness. :(
> >
> > As you wrote, this enum is already commingled by partial commit
> > f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
> > with todo line in 2010 and commit b4a26a27287a ("IB: Report using RoCE
> > IP based gids in port caps") in 2014.
No, f931551bafe1 is fine, IB_PORT_OTHER_LOCAL_CHANGES_SUP is already
defined by the IBA as bit 26.
It is b4a26a27287a that screwed this up.
> > More on that, IBTA declares those bits as needed for SM entities
> > (C14-24.1.1) and it doesn't mean that we should limit everything to MADs.
In the kernel it is the definition of attrs->port_cap_bask that it is
the value from the MAD. Nothing else is acceptable.
> When we discussed this in the past we agreed that while IBTA defines
> the wire bits and must be compliant by all vendors, the SW
> representation is Linux verbs specific and does not have to match
> exactly to the IBTA wire definitions.
Okay *maybe* for verbs (and even that is a terrible idea, but we are
stuck with it) but certainly not for sysfs or netlink which expose
port_cap_flags thinking it is the PortInfo CapabilityMask.
So first we need to fix the damage caused by b4a26a27287a, then we can
redo this patch. I'll send a patch today.
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
