> On Nov 19, 2018, at 5:41 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Mon, Nov 19, 2018 at 08:16:37AM -0800, Bart Van Assche wrote: >> On Mon, 2018-11-19 at 10:45 -0500, Chuck Lever wrote: >>> FMR is not supported on most recent RDMA devices. It is also slower >>> and less secure than FRWR. As discussed during the RDMA BoF at LPC >>> 2018, it is time to remove support for FMR in the NFS/RDMA client >>> stack. NFS/RDMA server-side uses either local memory registration or >>> FRWR. There is no change required there to deprecate FMR. >>> >>> There are a few Infiniband/RoCE devices in the kernel tree that do >>> not support MEM_MGT_EXTENSIONS, and therefore will no longer support >>> client-side NFS/RDMA. These are: >>> >>> - mthca >>> - qib > > Ooh, qib was not in the list when we talked on this in plumbers. That > does change things. > > Dennis: Could qib be changed? HFI1 supports FRWR right? > >>> - usnic >>> - hns (RoCE) >> >> Can someone from Intel comment on how many of their customers rely on the qib >> driver? >> >> Can someone from Cisco comment on how many of their customers rely on the usnic >> driver? > > Ignore usnic, it is not a RDMA driver > >> Can someone from Huawei comment on how many of their customers rely on the hns >> driver? > > Nor was this, this is an actively used driver.. > > Could hns do FRWR? It is very disappointing that such a new driver > does not support FRWR. > > I guess it is worth stating again that FMR is deprecated. People are > going to be disappointed if they try to submit new drivers that don't > support FRWR :( My methodology was to search for whether each driver asserts IB_DEVICE_MEM_MGT_EXTENSIONS in device_cap_flags. Interestingly, nes and ocrdma assert it, but qib and hns do not. -- Chuck Lever
