Re: [PATCH for-rc v1 0/4] RDMA/providers: Set max_pkey attribute

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jul 07, 2020 at 10:13:24PM +0300, Kamal Heib wrote:
> On Tue, Jul 07, 2020 at 01:12:47PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jul 06, 2020 at 12:11:15PM +0300, Kamal Heib wrote:
> > > This patch set makes sure to set the max_pkeys attribute to the providers
> > > that aren't setting it or not setting it correctly.
> > > 
> > > v1: Drop the efa patch and target for-rc.
> > > 
> > > Kamal Heib (4):
> > >   RDMA/siw: Set max_pkeys attribute
> > >   RDMA/cxgb4: Set max_pkeys attribute
> > >   RDMA/i40iw: Set max_pkeys attribute
> > >   RDMA/usnic: Fix reported max_pkeys attribute
> > 
> > Why should iwarp have a 1 pkey value?
> > 
> > Jason
> 
> That is a good question :-)
> 
> My Idea in this patchset was to match between the reported pkey_tbl_len and
> the max_pkeys attribute that the providers expose.
> 
> But after taking a deeper look now, I see that the RDMA core requires
> from all providers to implement the query_pkey() callback, which before
> [1] commit that will cause the provider driver not to load. For IB
> providers the requirement make sense, also for RoCE providers, because
> there is a requirement by the RoCE Spec to support the default PKey, For
> iwarp providers, This doesn't make sense and I think that they decided to
> do the same as RoCE and to avoid the driver load failure.
> 
> Probably, The requirement from the RDMA core needs to be changed and
> the query_pkey() callback needs to be removed from the iwarp providers,
> Thoughts?

Sure

But then the pkey table size is 0 right?

Jason