From: Jason Gunthorpe <jgg@nvidia.com>
To: Haoyue Xu <xuhaoyue1@hisilicon.com>
Cc: leon@kernel.org, linux-rdma@vger.kernel.org, linuxarm@huawei.com
Subject: Re: [RFC PATCH for-next 3/3] libhns: Add support for SVE Direct WQE function
Date: Wed, 22 Mar 2023 16:02:47 -0300 [thread overview]
Message-ID: <ZBtQ1/3WjWNXAT/b@nvidia.com> (raw)
In-Reply-To: <20230225100253.3993383-4-xuhaoyue1@hisilicon.com>
On Sat, Feb 25, 2023 at 06:02:53PM +0800, Haoyue Xu wrote:
> +
> +set_source_files_properties(hns_roce_u_hw_v2.c PROPERTIES COMPILE_FLAGS "${SVE_FLAGS}")
> diff --git a/providers/hns/hns_roce_u_hw_v2.c b/providers/hns/hns_roce_u_hw_v2.c
> index 3a294968..bd457217 100644
> --- a/providers/hns/hns_roce_u_hw_v2.c
> +++ b/providers/hns/hns_roce_u_hw_v2.c
> @@ -299,6 +299,11 @@ static void hns_roce_update_sq_db(struct hns_roce_context *ctx,
> hns_roce_write64(qp->sq.db_reg, (__le32 *)&sq_db);
> }
>
> +static void hns_roce_sve_write512(uint64_t *dest, uint64_t *val)
> +{
> + mmio_memcpy_x64_sve(dest, val);
> +}
This is not the right way, you should make this work like the x86 SSE
stuff, using a "__attribute__((target(xx)))"
Look in util/mmio.c and implement a mmio_memcpy_x64 for ARM SVE
mmio_memcpy_x64 is defined to try to generate a 64 byte PCI-E TLP.
If you don't want or can't handle that then you should write your own
loop of 8 byte stores.
> static void hns_roce_write512(uint64_t *dest, uint64_t *val)
> {
> mmio_memcpy_x64(dest, val, sizeof(struct hns_roce_rc_sq_wqe));
> @@ -314,7 +319,10 @@ static void hns_roce_write_dwqe(struct hns_roce_qp *qp, void *wqe)
> hr_reg_write(rc_sq_wqe, RCWQE_DB_SL_H, qp->sl >> HNS_ROCE_SL_SHIFT);
> hr_reg_write(rc_sq_wqe, RCWQE_WQE_IDX, qp->sq.head);
>
> - hns_roce_write512(qp->sq.db_reg, wqe);
> + if (qp->flags & HNS_ROCE_QP_CAP_SVE_DIRECT_WQE)
Why do you need a device flag here?
> + hns_roce_sve_write512(qp->sq.db_reg, wqe);
> + else
> + hns_roce_write512(qp->sq.db_reg, wqe);
Isn't this function being called on WC memory already? The usual way
to make the 64 byte write is with stores to WC memory..
Jason
next prev parent reply other threads:[~2023-03-22 19:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-25 10:02 [RFC PATCH for-next 0/1] Add SVE ldr and str instruction Haoyue Xu
2023-02-25 10:02 ` [RFC PATCH for-next 1/1] RDMA/hns: Add SVE DIRECT WQE flag to support libhns Haoyue Xu
2023-02-25 10:02 ` [RFC PATCH for-next 2/3] Update kernel headers Haoyue Xu
2023-02-25 10:02 ` [RFC PATCH for-next 3/3] libhns: Add support for SVE Direct WQE function Haoyue Xu
2023-03-22 19:02 ` Jason Gunthorpe [this message]
2023-03-27 12:53 ` xuhaoyue (A)
2023-03-27 12:55 ` Jason Gunthorpe
2023-03-30 12:57 ` xuhaoyue (A)
2023-03-30 13:01 ` Jason Gunthorpe
2023-03-31 3:38 ` xuhaoyue (A)
2023-03-31 11:39 ` Jason Gunthorpe
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=ZBtQ1/3WjWNXAT/b@nvidia.com \
--to=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=xuhaoyue1@hisilicon.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.