Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/16/2018 3:22 PM, Håkon Bugge wrote: > But, do we need an update to IBTA (that the BTH.PKey shall be that of the > VM's Port)? Nothing in spec mentions shared (port) virtualization so that is an exercise completely left to the reader... Annex A19 is silent on this specific point but the

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/16/2018 3:22 PM, Håkon Bugge wrote: > But, do we need an update to IBTA (that the BTH.PKey shall be that of the > VM's Port)? Nothing in spec mentions shared (port) virtualization so that is an exercise completely left to the reader... Annex A19 is silent on this specific point but the

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 08:14:50PM +0200, Håkon Bugge wrote: > > > > On 16 May 2018, at 20:01, Jason Gunthorpe wrote: > > > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > > > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, > >>

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 08:14:50PM +0200, Håkon Bugge wrote: > > > > On 16 May 2018, at 20:01, Jason Gunthorpe wrote: > > > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > > > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, > >> 0x0001. > >> > >>

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 16 May 2018, at 20:01, Jason Gunthorpe wrote: > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, >> 0x0001. >> >> The wce.pkey_index is 1 (i.e., pointing to 0x8001). Now, tell me,

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 16 May 2018, at 20:01, Jason Gunthorpe wrote: > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, >> 0x0001. >> >> The wce.pkey_index is 1 (i.e., pointing to 0x8001). Now, tell me, was >>

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 07:46:10PM +0200, Håkon Bugge wrote: >OK. Lets take one example. The pkey table contains 0x, 0x8001, >0x0001. > >The wce.pkey_index is 1 (i.e., pointing to 0x8001). Now, tell me, was >BTH.PKey 0x8001 (matches 0x8001) or was it 0x0001 (also matching >

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 07:46:10PM +0200, Håkon Bugge wrote: >OK. Lets take one example. The pkey table contains 0x, 0x8001, >0x0001. > >The wce.pkey_index is 1 (i.e., pointing to 0x8001). Now, tell me, was >BTH.PKey 0x8001 (matches 0x8001) or was it 0x0001 (also matching >

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,

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,

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/16/2018 11:12 AM, Jason Gunthorpe wrote: > On Wed, May 16, 2018 at 08:47:21AM +0200, Håkon Bugge wrote: > >>> This is not a difficult issue. >>> >>> If the GMP is properly tagged with the right PKey then it will never >>> be delivered to the VM if the VM does not have the PKey in the >>>

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/16/2018 11:12 AM, Jason Gunthorpe wrote: > On Wed, May 16, 2018 at 08:47:21AM +0200, Håkon Bugge wrote: > >>> This is not a difficult issue. >>> >>> If the GMP is properly tagged with the right PKey then it will never >>> be delivered to the VM if the VM does not have the PKey in the >>>

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 08:47:21AM +0200, Håkon Bugge wrote: > > This is not a difficult issue. > > > > If the GMP is properly tagged with the right PKey then it will never > > be delivered to the VM if the VM does not have the PKey in the > > table. > > Not quite right. For the shared port

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 08:47:21AM +0200, Håkon Bugge wrote: > > This is not a difficult issue. > > > > If the GMP is properly tagged with the right PKey then it will never > > be delivered to the VM if the VM does not have the PKey in the > > table. > > Not quite right. For the shared port

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 21:04, Jason Gunthorpe wrote: > > On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: >>> On 15 May 2018, at 02:38, Hal Rosenstock wrote: >>> >>> On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: On Thu, May 10, 2018 at

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 21:04, Jason Gunthorpe wrote: > > On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: >>> On 15 May 2018, at 02:38, Hal Rosenstock wrote: >>> >>> On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote:

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: > > On 15 May 2018, at 02:38, Hal Rosenstock wrote: > > > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: > >> On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote: > >> > >>> We are talking about two

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: > > On 15 May 2018, at 02:38, Hal Rosenstock wrote: > > > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: > >> On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote: > >> > >>> We are talking about two things here. The PKey in

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 02:38, Hal Rosenstock wrote: > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: >> 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.

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 02:38, Hal Rosenstock wrote: > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: >> 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

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: > 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

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: > 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

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On Fri, May 11, 2018 at 12:55:00PM +0200, Håkon Bugge wrote: > > I'll check upstream OpenSM when I get a chance to see if same problem > > exists. Oracle OpenSM forked from upstream long time ago and not sure > > how similar the path record code is. There were various impacts for the > > shared

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On Fri, May 11, 2018 at 12:55:00PM +0200, Håkon Bugge wrote: > > I'll check upstream OpenSM when I get a chance to see if same problem > > exists. Oracle OpenSM forked from upstream long time ago and not sure > > how similar the path record code is. There were various impacts for the > > shared

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

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

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

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

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/11/2018 6:55 AM, Håkon Bugge wrote: > > >> On 10 May 2018, at 18:54, Hal Rosenstock wrote: >> >> On 5/10/2018 11:16 AM, Håkon Bugge wrote: >>> >>> On 10 May 2018, at 16:01, Hal Rosenstock wrote: On 5/10/2018 5:16 AM, Håkon

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/11/2018 6:55 AM, Håkon Bugge wrote: > > >> On 10 May 2018, at 18:54, Hal Rosenstock wrote: >> >> On 5/10/2018 11:16 AM, Håkon Bugge wrote: >>> >>> On 10 May 2018, at 16:01, Hal Rosenstock wrote: On 5/10/2018 5:16 AM, Håkon Bugge wrote: > > >> On 9 May 2018, at

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 18:54, Hal Rosenstock wrote: > > On 5/10/2018 11:16 AM, Håkon Bugge wrote: >> >> >>> On 10 May 2018, at 16:01, Hal Rosenstock wrote: >>> >>> On 5/10/2018 5:16 AM, Håkon Bugge wrote: > On 9 May 2018, at

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 18:54, Hal Rosenstock wrote: > > On 5/10/2018 11:16 AM, Håkon Bugge wrote: >> >> >>> On 10 May 2018, at 16:01, Hal Rosenstock wrote: >>> >>> On 5/10/2018 5:16 AM, Håkon Bugge wrote: > On 9 May 2018, at 13:28, Hal Rosenstock wrote: > > On

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/10/2018 11:16 AM, Håkon Bugge wrote: > > >> On 10 May 2018, at 16:01, Hal Rosenstock wrote: >> >> On 5/10/2018 5:16 AM, Håkon Bugge wrote: >>> >>> On 9 May 2018, at 13:28, Hal Rosenstock wrote: On 5/9/2018 5:30 AM, Håkon

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/10/2018 11:16 AM, Håkon Bugge wrote: > > >> On 10 May 2018, at 16:01, Hal Rosenstock wrote: >> >> On 5/10/2018 5:16 AM, Håkon Bugge wrote: >>> >>> On 9 May 2018, at 13:28, Hal Rosenstock wrote: On 5/9/2018 5:30 AM, Håkon Bugge wrote: > There is no point in using RDMA CM

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 16:01, Hal Rosenstock wrote: > > On 5/10/2018 5:16 AM, Håkon Bugge wrote: >> >> >>> On 9 May 2018, at 13:28, Hal Rosenstock wrote: >>> >>> On 5/9/2018 5:30 AM, Håkon Bugge wrote: There is no point in using RDMA CM

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 16:01, Hal Rosenstock wrote: > > On 5/10/2018 5:16 AM, Håkon Bugge wrote: >> >> >>> On 9 May 2018, at 13:28, Hal Rosenstock wrote: >>> >>> On 5/9/2018 5:30 AM, Håkon Bugge wrote: There is no point in using RDMA CM to establish a connection between two QPs

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/10/2018 5:16 AM, Håkon Bugge wrote: > > >> On 9 May 2018, at 13:28, Hal Rosenstock wrote: >> >> On 5/9/2018 5:30 AM, Håkon Bugge wrote: >>> There is no point in using RDMA CM to establish a connection between >>> two QPs that cannot possible communicate.

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/10/2018 5:16 AM, Håkon Bugge wrote: > > >> On 9 May 2018, at 13:28, Hal Rosenstock wrote: >> >> On 5/9/2018 5:30 AM, Håkon Bugge wrote: >>> There is no point in using RDMA CM to establish a connection between >>> two QPs that cannot possible communicate. Particularly, if both the >>>

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 9 May 2018, at 13:28, Hal Rosenstock wrote: > > On 5/9/2018 5:30 AM, Håkon Bugge wrote: >> There is no point in using RDMA CM to establish a connection between >> two QPs that cannot possible communicate. Particularly, if both the >> active and passive side use

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 9 May 2018, at 13:28, Hal Rosenstock wrote: > > On 5/9/2018 5:30 AM, Håkon Bugge wrote: >> There is no point in using RDMA CM to establish a connection between >> two QPs that cannot possible communicate. Particularly, if both the >> active and passive side use limited pkeys, they are not

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

Hi Håkon, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc4 next-20180509] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

Hi Håkon, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc4 next-20180509] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/9/2018 5:30 AM, Håkon Bugge wrote: > There is no point in using RDMA CM to establish a connection between > two QPs that cannot possible communicate. Particularly, if both the > active and passive side use limited pkeys, they are not able to > communicate. > > In order to detect this

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

On 5/9/2018 5:30 AM, Håkon Bugge wrote: > There is no point in using RDMA CM to establish a connection between > two QPs that cannot possible communicate. Particularly, if both the > active and passive side use limited pkeys, they are not able to > communicate. > > In order to detect this

[PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

There is no point in using RDMA CM to establish a connection between two QPs that cannot possible communicate. Particularly, if both the active and passive side use limited pkeys, they are not able to communicate. In order to detect this situation, the authentic pkey is used in the CM REQ

[PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

There is no point in using RDMA CM to establish a connection between two QPs that cannot possible communicate. Particularly, if both the active and passive side use limited pkeys, they are not able to communicate. In order to detect this situation, the authentic pkey is used in the CM REQ