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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox