> On Nov 11, 2015, at 11:29 AM, Sagi Grimberg <[email protected]> wrote: > > > >> An alternate explanation is that the provider is not setting >> device->max_sge_rd properly. rdma_read_chunks_lcl() seems to >> be the only thing in my copy of the kernel tree that relies on >> that value. >> >> I’ve reproduced the local length errors with CX-2 and CX-3 >> Pro, which both set that field to 32. If I artificially >> set that field to 30, I don’t see any issue. >> >> Is commit 18ebd40773bf correct? > > See my latest patchset "Handle mlx4 max_sge_rd correctly" (v2). > > It fixes exactly this. > Now you will be able to add your "Tested-by:" tag ;)
Confirmed that the current value (32) does not work, and that the proposed replacement (30) does work, in an NFS server that uses the _lcl path with mlx4. > It on Doug to take it... Noted that the NFS server’s _lcl path is the only kernel consumer of this value. Because the current NFS server does not use the _lcl path with mlx4 devices, maybe this fix is not needed in stable, unless the max_sge_rd field is visible to user space. However no future changes to the NFS server’s reader selection logic should be made until this fix, or one like it, is merged. And I recommend adding a "Fixes: 18ebd40773bf" tag. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
