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
