[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180516165739.GD25661@ziepe.ca>
Date: Wed, 16 May 2018 10:57:39 -0600
From: Jason Gunthorpe <jgg@...pe.ca>
To: Hal Rosenstock <hal@....mellanox.co.il>
Cc: Håkon Bugge <haakon.bugge@...cle.com>,
Doug Ledford <dledford@...hat.com>,
Don Hiatt <don.hiatt@...el.com>,
Ira Weiny <ira.weiny@...el.com>,
Sean Hefty <sean.hefty@...el.com>,
OFED mailing list <linux-rdma@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and
check eligibility of the pkeys
On Wed, May 16, 2018 at 12:42:37PM -0400, Hal Rosenstock wrote:
> >>> The only time you could need a new REJ code is if the GMP is using a
> >>> PKey different from the REQ - which is a pretty goofy thing to do
> >>> considering this VM case.
> >>
> >> Its goofy. In the CX-3 shared port model, the BTH.PKey is the
> >> default one and the REQ.PKey is the full one even if the sending
> >> VM’s port only is a limited member. This patch series fixes the last
> >> issue.
> >
> > Again, this is wrong, the BTH.Pkey and REQ.Pkey should be the same -
>
> I do not believe there is anything in the spec that requires this. I
> agree it's the simplest use model though.
The spec doesn't require it, but the design of the Linux CM certainly
does.
> > If BTH.Pkey != REQ.PKey then the requestor side has to obviously
> > select two PKeys, which is basically impossible.
> >
> > The VM should not be part of the default partition, for instance.
>
> I think that the VM is at least a limited member of the default partition.
Well, being a limited member still means the default pkey cannot be
used for CM GMPs.
I actually can't think of why you'd want to do this, better to put the
SM nodes in all the pkeys and reserve the default pkey completely for
the network management control plane.
Jason
Powered by blists - more mailing lists