From: Daniel Gregory <daniel.gregory@bytedance.com>
To: "Stanisław Kardach" <stanislaw.kardach@gmail.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
dev@dpdk.org, Liang Ma <liangma@bytedance.com>,
Punit Agrawal <punit.agrawal@bytedance.com>
Subject: Re: [RFC PATCH] eal/riscv: add support for zawrs extension
Date: Mon, 20 May 2024 10:48:54 +0100 [thread overview]
Message-ID: <20240520094854.GA3672529@ste-uk-lab-gw> (raw)
In-Reply-To: <CAJcPQBrX+-XceJ0RTNEKTzHQQ9NH==nXnE2_dJJhh6Q=R9wVcA@mail.gmail.com>
On Sun, May 12, 2024 at 09:10:49AM +0200, Stanisław Kardach wrote:
> On Thu, May 2, 2024 at 4:44 PM Daniel Gregory
> <daniel.gregory@bytedance.com> wrote:
> > diff --git a/config/riscv/meson.build b/config/riscv/meson.build
> > index 07d7d9da23..4cfdc42ecb 100644
> > --- a/config/riscv/meson.build
> > +++ b/config/riscv/meson.build
> > @@ -26,6 +26,11 @@ flags_common = [
> > # read from /proc/device-tree/cpus/timebase-frequency. This property is
> > # guaranteed on Linux, as riscv time_init() requires it.
> > ['RTE_RISCV_TIME_FREQ', 0],
> > +
> > + # Enable use of RISC-V Wait-on-Reservation-Set extension (Zawrs)
> > + # Mitigates looping when polling on memory locations
> > + # Make sure to add '_zawrs' to your target's -march below
> > + ['RTE_RISCV_ZAWRS', false]
> A bit orthogonal to this patch (or maybe not?)
> Should we perhaps add a Qemu target in meson.build which would have
> the modified -march for what qemu supports now?
Yes, I can see that being worth doing as part of this patch. In addition
to Zawrs for this patch, GCC 13+ should generate prefetch instructions
for __builtin_prefetch() (lib/eal/include/generic/rte_prefetch.h) if the
Zicbop extension is enabled. Any more in particular you think would
benefit or would it be best to add every extension GCC 14 supports?
> Or perhaps add machine detection logic based either on the "riscv,isa"
> cpu@0 property in the DT or RHCT ACPI table?
I have had a look and, at least on QEMU 9, this seems non-trivial. The
RHCT acpi table at /proc/cpuinfo doesn't list every extension present
(eg. it's missing Zawrs), and the DT, whilst complete, can't be fed
directly into GCC because QEMU reports several newer and non-ratified
extensions that GCC doesn't support yet.
> Or add perhaps some other way we could specify the extension list
> suffix for -march?
Setting -Dcpu_instruction_set to some arbitrary ISA could work with
somes minor changes to the build script to not discard it in favour of
rv64gc. Then, we could add a map from ISA extensions to flags that are
enabled when that extension is present in cpu_instruction_set?
Thanks for your review,
Daniel
next prev parent reply other threads:[~2024-05-20 9:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 14:41 Daniel Gregory
2024-05-08 11:48 ` Stanisław Kardach
2024-05-12 7:10 ` Stanisław Kardach
2024-05-20 9:48 ` Daniel Gregory [this message]
2024-05-20 15:43 ` [External] " Punit Agrawal
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=20240520094854.GA3672529@ste-uk-lab-gw \
--to=daniel.gregory@bytedance.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=liangma@bytedance.com \
--cc=punit.agrawal@bytedance.com \
--cc=stanislaw.kardach@gmail.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;
as well as URLs for NNTP newsgroup(s).