On Thu, May 30, 2019 at 05:34:53PM +0300, Yuval Shaia wrote: > On Thu, May 30, 2019 at 12:37:18PM +0000, Michal Kalderon wrote: > > > From: linux-rdma-owner@xxxxxxxxxxxxxxx <linux-rdma- > > > owner@xxxxxxxxxxxxxxx> On Behalf Of Yuval Shaia > > > > > > The virtual address that is registered is used as a base for any address passed > > > later in post_recv and post_send operations. > > > > > > On a virtualized environment this is not correct. > > > > > > A guest cannot register its memory so hypervisor maps the guest physical > > > address to a host virtual address and register it with the HW. Later on, at > > > datapath phase, the guest fills the SGEs with addresses from its address > > > space. > > > Since HW cannot access guest virtual address space an extra translation is > > > needed to map those addresses to be based on the host virtual address that > > > was registered with the HW. > > > This datapath interference affects performances. > > > > > > To avoid this, a logical separation between the address that is registered and > > > the address that is used as a offset at datapath phase is needed. > > > This separation is already implemented in the lower layer part > > > (ibv_cmd_reg_mr) but blocked at the API level. > > > > > > Fix it by introducing a new API function which accepts an address from guest > > > virtual address space as well, to be used as offset for later datapath > > > operations. > > > > > Could you give an example of how an app would use this new API? How will > > It receive the new hca_va addresss ? > > In my use case an application is device emulation that runs in the context > of a userspace process in the host. > This (virtual) device receives from guest driver a dma address (in form of > scatter-gather list) along with guest user-space virtual address. How do you handle the scatter-gather list? Jason
