* [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration
@ 2019-08-18 13:21 Yuval Shaia
2019-08-18 13:21 ` [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova Yuval Shaia
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Yuval Shaia @ 2019-08-18 13:21 UTC (permalink / raw)
To: berrange, thuth, philmd, pbonzini, laurent, qemu-devel,
yuval.shaia, marcel.apfelbaum
The virtual address that is provided by the guest in post_send and
post_recv operations is related to the guest address space. This
address
space is unknown to the HCA resides on host so extra step in these
operations is needed to adjust the address to host virtual address.
This step, which is done in data-path affects performances.
An enhanced verion of MR registration introduced here
https://patchwork.kernel.org/patch/11044467/ can be used so that the
guest virtual address space for this MR is known to the HCA in host.
This will save the data-path adjustment.
patch #1 deals with what is needed to detect if the library installed in
the host supports this function
patch #2 enhance the data-path ops by utilizing the new function
Yuval Shaia (2):
configure: Check if we can use ibv_reg_mr_iova
hw/rdma: Utilize ibv_reg_mr_iova for memory registration
configure | 28 ++++++++++++++++++++++++++++
hw/rdma/rdma_backend.c | 13 +++++++++++++
hw/rdma/rdma_backend.h | 5 +++++
hw/rdma/rdma_rm.c | 5 +++++
hw/rdma/vmw/pvrdma_main.c | 6 ++++++
5 files changed, 57 insertions(+)
--
2.20.1
^ permalink raw reply [flat|nested] 9+ messages in thread* [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova 2019-08-18 13:21 [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia @ 2019-08-18 13:21 ` Yuval Shaia 2019-08-31 19:28 ` Marcel Apfelbaum 2019-08-18 13:21 ` [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia ` (2 subsequent siblings) 3 siblings, 1 reply; 9+ messages in thread From: Yuval Shaia @ 2019-08-18 13:21 UTC (permalink / raw) To: berrange, thuth, philmd, pbonzini, laurent, qemu-devel, yuval.shaia, marcel.apfelbaum The function reg_mr_iova is an enhanced version of ibv_reg_mr function that can help to easly register and use guest's MRs. Add check in 'configure' phase to detect if we have libibverbs with this support. Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> --- configure | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/configure b/configure index 714e7fb6a1..e8e4a57b6f 100755 --- a/configure +++ b/configure @@ -3205,6 +3205,34 @@ else pvrdma="no" fi +# Let's see if enhanced reg_mr is supported +if test "$pvrdma" = "yes" ; then + +cat > $TMPC <<EOF && +#include <infiniband/verbs.h> + +int +main(void) +{ + struct ibv_mr *mr; + struct ibv_pd *pd = NULL; + size_t length = 10; + uint64_t iova = 0; + int access = 0; + void *addr = NULL; + + mr = ibv_reg_mr_iova(pd, addr, length, iova, access); + + ibv_dereg_mr(mr); + + return 0; +} +EOF + if ! compile_prog "" "-libverbs"; then + QEMU_CFLAGS="$QEMU_CFLAGS -DLEGACY_RDMA_REG_MR" + fi +fi + ########################################## # VNC SASL detection if test "$vnc" = "yes" && test "$vnc_sasl" != "no" ; then -- 2.20.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova 2019-08-18 13:21 ` [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova Yuval Shaia @ 2019-08-31 19:28 ` Marcel Apfelbaum 2019-09-01 9:25 ` Yuval Shaia 0 siblings, 1 reply; 9+ messages in thread From: Marcel Apfelbaum @ 2019-08-31 19:28 UTC (permalink / raw) To: Yuval Shaia, berrange, thuth, philmd, pbonzini, laurent, qemu-devel On 8/18/19 4:21 PM, Yuval Shaia wrote: > The function reg_mr_iova is an enhanced version of ibv_reg_mr function > that can help to easly register and use guest's MRs. > > Add check in 'configure' phase to detect if we have libibverbs with this > support. > > Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> > --- > configure | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/configure b/configure > index 714e7fb6a1..e8e4a57b6f 100755 > --- a/configure > +++ b/configure > @@ -3205,6 +3205,34 @@ else > pvrdma="no" > fi > > +# Let's see if enhanced reg_mr is supported > +if test "$pvrdma" = "yes" ; then > + > +cat > $TMPC <<EOF && > +#include <infiniband/verbs.h> > + > +int > +main(void) > +{ > + struct ibv_mr *mr; > + struct ibv_pd *pd = NULL; > + size_t length = 10; > + uint64_t iova = 0; > + int access = 0; > + void *addr = NULL; > + > + mr = ibv_reg_mr_iova(pd, addr, length, iova, access); Here you check if the API is changed, right? Can you query for a library version instead? Thanks, Marcel > + > + ibv_dereg_mr(mr); > + > + return 0; > +} > +EOF > + if ! compile_prog "" "-libverbs"; then > + QEMU_CFLAGS="$QEMU_CFLAGS -DLEGACY_RDMA_REG_MR" > + fi > +fi > + > ########################################## > # VNC SASL detection > if test "$vnc" = "yes" && test "$vnc_sasl" != "no" ; then ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova 2019-08-31 19:28 ` Marcel Apfelbaum @ 2019-09-01 9:25 ` Yuval Shaia 0 siblings, 0 replies; 9+ messages in thread From: Yuval Shaia @ 2019-09-01 9:25 UTC (permalink / raw) To: Marcel Apfelbaum; +Cc: thuth, berrange, qemu-devel, laurent, pbonzini, philmd On Sat, Aug 31, 2019 at 10:28:18PM +0300, Marcel Apfelbaum wrote: > > > On 8/18/19 4:21 PM, Yuval Shaia wrote: > > The function reg_mr_iova is an enhanced version of ibv_reg_mr function > > that can help to easly register and use guest's MRs. > > > > Add check in 'configure' phase to detect if we have libibverbs with this > > support. > > > > Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> > > --- > > configure | 28 ++++++++++++++++++++++++++++ > > 1 file changed, 28 insertions(+) > > > > diff --git a/configure b/configure > > index 714e7fb6a1..e8e4a57b6f 100755 > > --- a/configure > > +++ b/configure > > @@ -3205,6 +3205,34 @@ else > > pvrdma="no" > > fi > > +# Let's see if enhanced reg_mr is supported > > +if test "$pvrdma" = "yes" ; then > > + > > +cat > $TMPC <<EOF && > > +#include <infiniband/verbs.h> > > + > > +int > > +main(void) > > +{ > > + struct ibv_mr *mr; > > + struct ibv_pd *pd = NULL; > > + size_t length = 10; > > + uint64_t iova = 0; > > + int access = 0; > > + void *addr = NULL; > > + > > + mr = ibv_reg_mr_iova(pd, addr, length, iova, access); > > Here you check if the API is changed, right? Yes. > Can you query for a library version instead? Library version is set in the spec file which is under the distros'es responsibility. I don't see a reason to be depend on that especially when the check for support is so easy. In addition, this way allows one to download latest upstream code and compile against it even when his distro still didn't update the repo. > > Thanks, > Marcel > > > + > > + ibv_dereg_mr(mr); > > + > > + return 0; > > +} > > +EOF > > + if ! compile_prog "" "-libverbs"; then > > + QEMU_CFLAGS="$QEMU_CFLAGS -DLEGACY_RDMA_REG_MR" > > + fi > > +fi > > + > > ########################################## > > # VNC SASL detection > > if test "$vnc" = "yes" && test "$vnc_sasl" != "no" ; then > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration 2019-08-18 13:21 [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia 2019-08-18 13:21 ` [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova Yuval Shaia @ 2019-08-18 13:21 ` Yuval Shaia 2019-08-31 19:31 ` Marcel Apfelbaum 2019-08-31 19:26 ` [Qemu-devel] [PATCH 0/2] rdma: " Marcel Apfelbaum 2019-11-05 11:23 ` Marcel Apfelbaum 3 siblings, 1 reply; 9+ messages in thread From: Yuval Shaia @ 2019-08-18 13:21 UTC (permalink / raw) To: berrange, thuth, philmd, pbonzini, laurent, qemu-devel, yuval.shaia, marcel.apfelbaum The virtual address that is provided by the guest in post_send and post_recv operations is related to the guest address space. This address space is unknown to the HCA resides on host so extra step in these operations is needed to adjust the address to host virtual address. This step, which is done in data-path affects performances. An enhanced verion of MR registration introduced here https://patchwork.kernel.org/patch/11044467/ can be used so that the guest virtual address space for this MR is known to the HCA in host. This will save the data-path adjustment. Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> --- hw/rdma/rdma_backend.c | 13 +++++++++++++ hw/rdma/rdma_backend.h | 5 +++++ hw/rdma/rdma_rm.c | 5 +++++ hw/rdma/vmw/pvrdma_main.c | 6 ++++++ 4 files changed, 29 insertions(+) diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c index c39051068d..c346407cd3 100644 --- a/hw/rdma/rdma_backend.c +++ b/hw/rdma/rdma_backend.c @@ -391,7 +391,11 @@ static int build_host_sge_array(RdmaDeviceResources *rdma_dev_res, return VENDOR_ERR_INVLKEY | ssge[ssge_idx].lkey; } +#ifdef LEGACY_RDMA_REG_MR dsge->addr = (uintptr_t)mr->virt + ssge[ssge_idx].addr - mr->start; +#else + dsge->addr = ssge[ssge_idx].addr; +#endif dsge->length = ssge[ssge_idx].length; dsge->lkey = rdma_backend_mr_lkey(&mr->backend_mr); @@ -735,10 +739,19 @@ void rdma_backend_destroy_pd(RdmaBackendPD *pd) } } +#ifdef LEGACY_RDMA_REG_MR int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, size_t length, int access) +#else +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, + size_t length, uint64_t guest_start, int access) +#endif { +#ifdef LEGACY_RDMA_REG_MR mr->ibmr = ibv_reg_mr(pd->ibpd, addr, length, access); +#else + mr->ibmr = ibv_reg_mr_iova(pd->ibpd, addr, length, guest_start, access); +#endif if (!mr->ibmr) { rdma_error_report("ibv_reg_mr fail, errno=%d", errno); return -EIO; diff --git a/hw/rdma/rdma_backend.h b/hw/rdma/rdma_backend.h index 7c1a19a2b5..127f96e2d5 100644 --- a/hw/rdma/rdma_backend.h +++ b/hw/rdma/rdma_backend.h @@ -78,8 +78,13 @@ int rdma_backend_query_port(RdmaBackendDev *backend_dev, int rdma_backend_create_pd(RdmaBackendDev *backend_dev, RdmaBackendPD *pd); void rdma_backend_destroy_pd(RdmaBackendPD *pd); +#ifdef LEGACY_RDMA_REG_MR int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, size_t length, int access); +#else +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, + size_t length, uint64_t guest_start, int access); +#endif void rdma_backend_destroy_mr(RdmaBackendMR *mr); int rdma_backend_create_cq(RdmaBackendDev *backend_dev, RdmaBackendCQ *cq, diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c index 1927f85472..1524dfaeaa 100644 --- a/hw/rdma/rdma_rm.c +++ b/hw/rdma/rdma_rm.c @@ -227,8 +227,13 @@ int rdma_rm_alloc_mr(RdmaDeviceResources *dev_res, uint32_t pd_handle, mr->length = guest_length; mr->virt += (mr->start & (TARGET_PAGE_SIZE - 1)); +#ifdef LEGACY_RDMA_REG_MR ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, mr->length, access_flags); +#else + ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, + mr->length, guest_start, access_flags); +#endif if (ret) { ret = -EIO; goto out_dealloc_mr; diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c index 3e36e13013..18075285f6 100644 --- a/hw/rdma/vmw/pvrdma_main.c +++ b/hw/rdma/vmw/pvrdma_main.c @@ -664,6 +664,12 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp) dev->shutdown_notifier.notify = pvrdma_shutdown_notifier; qemu_register_shutdown_notifier(&dev->shutdown_notifier); +#ifdef LEGACY_RDMA_REG_MR + rdma_info_report("Using legacy reg_mr"); +#else + rdma_info_report("Using iova reg_mr"); +#endif + out: if (rc) { pvrdma_fini(pdev); -- 2.20.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration 2019-08-18 13:21 ` [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia @ 2019-08-31 19:31 ` Marcel Apfelbaum 2019-09-01 9:30 ` Yuval Shaia 0 siblings, 1 reply; 9+ messages in thread From: Marcel Apfelbaum @ 2019-08-31 19:31 UTC (permalink / raw) To: Yuval Shaia, berrange, thuth, philmd, pbonzini, laurent, qemu-devel Hi Yuval, On 8/18/19 4:21 PM, Yuval Shaia wrote: > The virtual address that is provided by the guest in post_send and > post_recv operations is related to the guest address space. This address > space is unknown to the HCA resides on host so extra step in these > operations is needed to adjust the address to host virtual address. > > This step, which is done in data-path affects performances. > > An enhanced verion of MR registration introduced here > https://patchwork.kernel.org/patch/11044467/ can be used so that the > guest virtual address space for this MR is known to the HCA in host. > > This will save the data-path adjustment. > > Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> > --- > hw/rdma/rdma_backend.c | 13 +++++++++++++ > hw/rdma/rdma_backend.h | 5 +++++ > hw/rdma/rdma_rm.c | 5 +++++ > hw/rdma/vmw/pvrdma_main.c | 6 ++++++ > 4 files changed, 29 insertions(+) > > diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c > index c39051068d..c346407cd3 100644 > --- a/hw/rdma/rdma_backend.c > +++ b/hw/rdma/rdma_backend.c > @@ -391,7 +391,11 @@ static int build_host_sge_array(RdmaDeviceResources *rdma_dev_res, > return VENDOR_ERR_INVLKEY | ssge[ssge_idx].lkey; > } > > +#ifdef LEGACY_RDMA_REG_MR > dsge->addr = (uintptr_t)mr->virt + ssge[ssge_idx].addr - mr->start; This is the performance hit you are addressing? The address computation? Thanks, Marcel > +#else > + dsge->addr = ssge[ssge_idx].addr; > +#endif > dsge->length = ssge[ssge_idx].length; > dsge->lkey = rdma_backend_mr_lkey(&mr->backend_mr); > > @@ -735,10 +739,19 @@ void rdma_backend_destroy_pd(RdmaBackendPD *pd) > } > } > > +#ifdef LEGACY_RDMA_REG_MR > int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > size_t length, int access) > +#else > +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > + size_t length, uint64_t guest_start, int access) > +#endif > { > +#ifdef LEGACY_RDMA_REG_MR > mr->ibmr = ibv_reg_mr(pd->ibpd, addr, length, access); > +#else > + mr->ibmr = ibv_reg_mr_iova(pd->ibpd, addr, length, guest_start, access); > +#endif > if (!mr->ibmr) { > rdma_error_report("ibv_reg_mr fail, errno=%d", errno); > return -EIO; > diff --git a/hw/rdma/rdma_backend.h b/hw/rdma/rdma_backend.h > index 7c1a19a2b5..127f96e2d5 100644 > --- a/hw/rdma/rdma_backend.h > +++ b/hw/rdma/rdma_backend.h > @@ -78,8 +78,13 @@ int rdma_backend_query_port(RdmaBackendDev *backend_dev, > int rdma_backend_create_pd(RdmaBackendDev *backend_dev, RdmaBackendPD *pd); > void rdma_backend_destroy_pd(RdmaBackendPD *pd); > > +#ifdef LEGACY_RDMA_REG_MR > int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > size_t length, int access); > +#else > +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > + size_t length, uint64_t guest_start, int access); > +#endif > void rdma_backend_destroy_mr(RdmaBackendMR *mr); > > int rdma_backend_create_cq(RdmaBackendDev *backend_dev, RdmaBackendCQ *cq, > diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c > index 1927f85472..1524dfaeaa 100644 > --- a/hw/rdma/rdma_rm.c > +++ b/hw/rdma/rdma_rm.c > @@ -227,8 +227,13 @@ int rdma_rm_alloc_mr(RdmaDeviceResources *dev_res, uint32_t pd_handle, > mr->length = guest_length; > mr->virt += (mr->start & (TARGET_PAGE_SIZE - 1)); > > +#ifdef LEGACY_RDMA_REG_MR > ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, > mr->length, access_flags); > +#else > + ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, > + mr->length, guest_start, access_flags); > +#endif > if (ret) { > ret = -EIO; > goto out_dealloc_mr; > diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c > index 3e36e13013..18075285f6 100644 > --- a/hw/rdma/vmw/pvrdma_main.c > +++ b/hw/rdma/vmw/pvrdma_main.c > @@ -664,6 +664,12 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp) > dev->shutdown_notifier.notify = pvrdma_shutdown_notifier; > qemu_register_shutdown_notifier(&dev->shutdown_notifier); > > +#ifdef LEGACY_RDMA_REG_MR > + rdma_info_report("Using legacy reg_mr"); > +#else > + rdma_info_report("Using iova reg_mr"); > +#endif > + > out: > if (rc) { > pvrdma_fini(pdev); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration 2019-08-31 19:31 ` Marcel Apfelbaum @ 2019-09-01 9:30 ` Yuval Shaia 0 siblings, 0 replies; 9+ messages in thread From: Yuval Shaia @ 2019-09-01 9:30 UTC (permalink / raw) To: Marcel Apfelbaum; +Cc: thuth, berrange, qemu-devel, laurent, pbonzini, philmd On Sat, Aug 31, 2019 at 10:31:57PM +0300, Marcel Apfelbaum wrote: > Hi Yuval, > > On 8/18/19 4:21 PM, Yuval Shaia wrote: > > The virtual address that is provided by the guest in post_send and > > post_recv operations is related to the guest address space. This address > > space is unknown to the HCA resides on host so extra step in these > > operations is needed to adjust the address to host virtual address. > > > > This step, which is done in data-path affects performances. > > > > An enhanced verion of MR registration introduced here > > https://patchwork.kernel.org/patch/11044467/ can be used so that the > > guest virtual address space for this MR is known to the HCA in host. > > > > This will save the data-path adjustment. > > > > Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> > > --- > > hw/rdma/rdma_backend.c | 13 +++++++++++++ > > hw/rdma/rdma_backend.h | 5 +++++ > > hw/rdma/rdma_rm.c | 5 +++++ > > hw/rdma/vmw/pvrdma_main.c | 6 ++++++ > > 4 files changed, 29 insertions(+) > > > > diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c > > index c39051068d..c346407cd3 100644 > > --- a/hw/rdma/rdma_backend.c > > +++ b/hw/rdma/rdma_backend.c > > @@ -391,7 +391,11 @@ static int build_host_sge_array(RdmaDeviceResources *rdma_dev_res, > > return VENDOR_ERR_INVLKEY | ssge[ssge_idx].lkey; > > } > > +#ifdef LEGACY_RDMA_REG_MR > > dsge->addr = (uintptr_t)mr->virt + ssge[ssge_idx].addr - mr->start; > > This is the performance hit you are addressing? The address computation? This is the support for legacy library, see below the enhancement. > > Thanks, > Marcel > > > > +#else > > + dsge->addr = ssge[ssge_idx].addr; Here it is, no need to adjust to host virtual address. Please note also that this is a huge step toward virtio-rdma support where the emulation will be bypassed in data path so no chance for address adjustment. > > +#endif > > dsge->length = ssge[ssge_idx].length; > > dsge->lkey = rdma_backend_mr_lkey(&mr->backend_mr); > > @@ -735,10 +739,19 @@ void rdma_backend_destroy_pd(RdmaBackendPD *pd) > > } > > } > > +#ifdef LEGACY_RDMA_REG_MR > > int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > > size_t length, int access) > > +#else > > +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > > + size_t length, uint64_t guest_start, int access) > > +#endif > > { > > +#ifdef LEGACY_RDMA_REG_MR > > mr->ibmr = ibv_reg_mr(pd->ibpd, addr, length, access); > > +#else > > + mr->ibmr = ibv_reg_mr_iova(pd->ibpd, addr, length, guest_start, access); > > +#endif > > if (!mr->ibmr) { > > rdma_error_report("ibv_reg_mr fail, errno=%d", errno); > > return -EIO; > > diff --git a/hw/rdma/rdma_backend.h b/hw/rdma/rdma_backend.h > > index 7c1a19a2b5..127f96e2d5 100644 > > --- a/hw/rdma/rdma_backend.h > > +++ b/hw/rdma/rdma_backend.h > > @@ -78,8 +78,13 @@ int rdma_backend_query_port(RdmaBackendDev *backend_dev, > > int rdma_backend_create_pd(RdmaBackendDev *backend_dev, RdmaBackendPD *pd); > > void rdma_backend_destroy_pd(RdmaBackendPD *pd); > > +#ifdef LEGACY_RDMA_REG_MR > > int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > > size_t length, int access); > > +#else > > +int rdma_backend_create_mr(RdmaBackendMR *mr, RdmaBackendPD *pd, void *addr, > > + size_t length, uint64_t guest_start, int access); > > +#endif > > void rdma_backend_destroy_mr(RdmaBackendMR *mr); > > int rdma_backend_create_cq(RdmaBackendDev *backend_dev, RdmaBackendCQ *cq, > > diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c > > index 1927f85472..1524dfaeaa 100644 > > --- a/hw/rdma/rdma_rm.c > > +++ b/hw/rdma/rdma_rm.c > > @@ -227,8 +227,13 @@ int rdma_rm_alloc_mr(RdmaDeviceResources *dev_res, uint32_t pd_handle, > > mr->length = guest_length; > > mr->virt += (mr->start & (TARGET_PAGE_SIZE - 1)); > > +#ifdef LEGACY_RDMA_REG_MR > > ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, > > mr->length, access_flags); > > +#else > > + ret = rdma_backend_create_mr(&mr->backend_mr, &pd->backend_pd, mr->virt, > > + mr->length, guest_start, access_flags); > > +#endif > > if (ret) { > > ret = -EIO; > > goto out_dealloc_mr; > > diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c > > index 3e36e13013..18075285f6 100644 > > --- a/hw/rdma/vmw/pvrdma_main.c > > +++ b/hw/rdma/vmw/pvrdma_main.c > > @@ -664,6 +664,12 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp) > > dev->shutdown_notifier.notify = pvrdma_shutdown_notifier; > > qemu_register_shutdown_notifier(&dev->shutdown_notifier); > > +#ifdef LEGACY_RDMA_REG_MR > > + rdma_info_report("Using legacy reg_mr"); > > +#else > > + rdma_info_report("Using iova reg_mr"); > > +#endif > > + > > out: > > if (rc) { > > pvrdma_fini(pdev); > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration 2019-08-18 13:21 [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia 2019-08-18 13:21 ` [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova Yuval Shaia 2019-08-18 13:21 ` [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia @ 2019-08-31 19:26 ` Marcel Apfelbaum 2019-11-05 11:23 ` Marcel Apfelbaum 3 siblings, 0 replies; 9+ messages in thread From: Marcel Apfelbaum @ 2019-08-31 19:26 UTC (permalink / raw) To: Yuval Shaia, berrange, thuth, philmd, pbonzini, laurent, qemu-devel Hi Yuval, On 8/18/19 4:21 PM, Yuval Shaia wrote: > The virtual address that is provided by the guest in post_send and > post_recv operations is related to the guest address space. This > address > space is unknown to the HCA resides on host so extra step in these > operations is needed to adjust the address to host virtual address. > > This step, which is done in data-path affects performances. > > An enhanced verion of MR registration introduced here > https://patchwork.kernel.org/patch/11044467/ can be used so that the > guest virtual address space for this MR is known to the HCA in host. Nice work on kernel side ! Thanks, Marcel > > This will save the data-path adjustment. > > patch #1 deals with what is needed to detect if the library installed in > the host supports this function > patch #2 enhance the data-path ops by utilizing the new function > > Yuval Shaia (2): > configure: Check if we can use ibv_reg_mr_iova > hw/rdma: Utilize ibv_reg_mr_iova for memory registration > > configure | 28 ++++++++++++++++++++++++++++ > hw/rdma/rdma_backend.c | 13 +++++++++++++ > hw/rdma/rdma_backend.h | 5 +++++ > hw/rdma/rdma_rm.c | 5 +++++ > hw/rdma/vmw/pvrdma_main.c | 6 ++++++ > 5 files changed, 57 insertions(+) > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration 2019-08-18 13:21 [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia ` (2 preceding siblings ...) 2019-08-31 19:26 ` [Qemu-devel] [PATCH 0/2] rdma: " Marcel Apfelbaum @ 2019-11-05 11:23 ` Marcel Apfelbaum 3 siblings, 0 replies; 9+ messages in thread From: Marcel Apfelbaum @ 2019-11-05 11:23 UTC (permalink / raw) To: Yuval Shaia, qemu-devel Hi Yuval, On 8/18/19 4:21 PM, Yuval Shaia wrote: > The virtual address that is provided by the guest in post_send and > post_recv operations is related to the guest address space. This > address > space is unknown to the HCA resides on host so extra step in these > operations is needed to adjust the address to host virtual address. > > This step, which is done in data-path affects performances. > > An enhanced verion of MR registration introduced here > https://patchwork.kernel.org/patch/11044467/ can be used so that the > guest virtual address space for this MR is known to the HCA in host. > > This will save the data-path adjustment. > > patch #1 deals with what is needed to detect if the library installed in > the host supports this function > patch #2 enhance the data-path ops by utilizing the new function > > Yuval Shaia (2): > configure: Check if we can use ibv_reg_mr_iova > hw/rdma: Utilize ibv_reg_mr_iova for memory registration > > configure | 28 ++++++++++++++++++++++++++++ > hw/rdma/rdma_backend.c | 13 +++++++++++++ > hw/rdma/rdma_backend.h | 5 +++++ > hw/rdma/rdma_rm.c | 5 +++++ > hw/rdma/vmw/pvrdma_main.c | 6 ++++++ > 5 files changed, 57 insertions(+) > Can you please rebase on master and add to the patchset your other patches? Thanks, Marcel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-05 11:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-18 13:21 [Qemu-devel] [PATCH 0/2] rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia 2019-08-18 13:21 ` [Qemu-devel] [PATCH 1/2] configure: Check if we can use ibv_reg_mr_iova Yuval Shaia 2019-08-31 19:28 ` Marcel Apfelbaum 2019-09-01 9:25 ` Yuval Shaia 2019-08-18 13:21 ` [Qemu-devel] [PATCH 2/2] hw/rdma: Utilize ibv_reg_mr_iova for memory registration Yuval Shaia 2019-08-31 19:31 ` Marcel Apfelbaum 2019-09-01 9:30 ` Yuval Shaia 2019-08-31 19:26 ` [Qemu-devel] [PATCH 0/2] rdma: " Marcel Apfelbaum 2019-11-05 11:23 ` Marcel Apfelbaum
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).