All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Wenpeng Liang <liangwenpeng@huawei.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	linux-rdma@vger.kernel.org, linuxarm@huawei.com
Subject: Re: [PATCH v4 for-next 1/1] RDMA/hns: Support direct wqe of userspace
Date: Fri, 26 Nov 2021 08:16:23 -0400	[thread overview]
Message-ID: <20211126121623.GQ4670@nvidia.com> (raw)
In-Reply-To: <9b3e8596-a386-667b-b8b2-21358331d681@huawei.com>

On Fri, Nov 26, 2021 at 04:25:27PM +0800, Wenpeng Liang wrote:
> On 2021/11/26 1:50, Jason Gunthorpe wrote:
> > On Mon, Nov 22, 2021 at 10:58:09AM +0200, Leon Romanovsky wrote:
> >> On Mon, Nov 22, 2021 at 11:38:01AM +0800, Wenpeng Liang wrote:
> >>> From: Yixing Liu <liuyixing1@huawei.com>
> >>>
> >>> Add direct wqe enable switch and address mapping.
> >>>
> >>> Signed-off-by: Yixing Liu <liuyixing1@huawei.com>
> >>> Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
> >>>  drivers/infiniband/hw/hns/hns_roce_device.h |  8 +--
> >>>  drivers/infiniband/hw/hns/hns_roce_main.c   | 38 ++++++++++++---
> >>>  drivers/infiniband/hw/hns/hns_roce_pd.c     |  3 ++
> >>>  drivers/infiniband/hw/hns/hns_roce_qp.c     | 54 ++++++++++++++++++++-
> >>>  include/uapi/rdma/hns-abi.h                 |  2 +
> >>>  5 files changed, 94 insertions(+), 11 deletions(-)
> >>
> >> <...>
> >>
> >>>  	entry = to_hns_mmap(rdma_entry);
> >>>  	pfn = entry->address >> PAGE_SHIFT;
> >>> -	prot = vma->vm_page_prot;
> >>>  
> >>> -	if (entry->mmap_type != HNS_ROCE_MMAP_TYPE_TPTR)
> >>> -		prot = pgprot_noncached(prot);
> >>> +	switch (entry->mmap_type) {
> >>> +	case HNS_ROCE_MMAP_TYPE_DB:
> >>> +		prot = pgprot_noncached(vma->vm_page_prot);
> >>> +		break;
> >>> +	case HNS_ROCE_MMAP_TYPE_TPTR:
> >>> +		prot = vma->vm_page_prot;
> >>> +		break;
> >>> +	case HNS_ROCE_MMAP_TYPE_DWQE:
> >>> +		prot = pgprot_device(vma->vm_page_prot);
> >>
> >> Everything fine, except this pgprot_device(). You probably need to check
> >> WC internally in your driver and use or pgprot_writecombine() or
> >> pgprot_noncached() explicitly.
> > 
> > pgprot_device is only used in two places in the kernel
> > pci_mmap_resource_range() for setting up the sysfs resourceXX mmap
> > 
> > And in pci_remap_iospace() as part of emulationg PIO on mmio
> > architectures
> > 
> > So, a PCI device should always be using pgprot_device() in its mmap
> > function
> > 
> > The question is why is pgprot_noncached() being used at all? The only
> > difference on ARM is that noncached is non-Early Write Acknowledgement
> > and devices is not.
> > 
> > At the very least this should be explained in a comment why nE vs E is
> > required in all these cases.
> > 
> > Jason
> > .
> > 
> 
> HIP09 is a SoC device, and our CPU only optimizes ST4 instructions for device
> attributes. Therefore, we set device attributes to obtain optimization effects.
> 
> The device attribute allows early ack, so it is faster compared with noncached.
> In order to ensure the early ack works correctly. Even if the data is incomplete,
> our device still knocks on the doorbell according to the content of the first
> 8 bytes to complete the data transmission.

That doesn't really explain why the doorbell needs to be mapped noncache

Jason

  reply	other threads:[~2021-11-26 12:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22  3:38 [PATCH v4 for-next 0/1] RDMA/hns: Support direct WQE of userspace Wenpeng Liang
2021-11-22  3:38 ` [PATCH v4 for-next 1/1] RDMA/hns: Support direct wqe " Wenpeng Liang
2021-11-22  8:58   ` Leon Romanovsky
2021-11-22  9:28     ` Wenpeng Liang
2021-11-22 11:10       ` Leon Romanovsky
2021-11-22 12:36         ` Wenpeng Liang
2021-11-25 17:50     ` Jason Gunthorpe
2021-11-26  8:25       ` Wenpeng Liang
2021-11-26 12:16         ` Jason Gunthorpe [this message]
2021-11-27  9:04           ` Wenpeng Liang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211126121623.GQ4670@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=leon@kernel.org \
    --cc=liangwenpeng@huawei.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.