summaryrefslogtreecommitdiffstats
path: root/mm/kmemleak.c
diff options
context:
space:
mode:
authorBryan Tan <bryantan@vmware.com>2019-10-28 18:14:52 +0000
committerJason Gunthorpe <jgg@mellanox.com>2019-10-28 16:09:23 -0300
commita52dc3a100958f4bf5e921067ba626c2caf8e55f (patch)
treea31dea3a46503be745de70c8970f31471bcc2f97 /mm/kmemleak.c
parentc9121262d57b8a3be4f08073546436ba0128ca6a (diff)
downloadlinux-a52dc3a100958f4bf5e921067ba626c2caf8e55f.tar.bz2
RDMA/vmw_pvrdma: Use resource ids from physical device if available
This change allows the RDMA stack to use physical resource numbers if they are passed up from the device. This is accomplished by separating the concept of the QP number from the QP handle. Previously, the two were the same, as the QP number was exposed to the guest and also used to reference a virtual QP in the device backend. With physical resource numbers exposed, the QP number given to the guest is the number assigned from the physical HCA's QP, while the QP handle is still the internal handle used to reference a virtual QP. Regardless of whether the device is exposing physical ids, the driver will still try to pick up the QP handle from the backend if possible. The MR keys exposed to the guest will also be the MR keys created by the physical HCA, instead of virtual MR keys. The distinction between handle and keys is already present for MRs so there is no need to do anything special here. A new version of the create QP response has been added to the device API to pass up the QP number and handle. The driver will also report these to userspace in the udata response if userspace supports it or not create the queuepair if not. I also had to do a refactor of the destroy qp code to reuse it if we fail to copy to userspace. Link: https://lore.kernel.org/r/20191028181444.19448-1-aditr@vmware.com Reviewed-by: Jorgen Hansen <jhansen@vmware.com> Signed-off-by: Adit Ranadive <aditr@vmware.com> Signed-off-by: Bryan Tan <bryantan@vmware.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Diffstat (limited to 'mm/kmemleak.c')
0 files changed, 0 insertions, 0 deletions