Re: [PATCH v3 1/8] eal: add initial support for RISC-V architecture

["Stanisław Kardach" <kda@semihalf.com>]

On Fri, May 13, 2022 at 5:37 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Fri, 13 May 2022 08:50:34 +0200
> Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote:
>
> > On 5/10/22 17:48, Stanislaw Kardach wrote:
> > > From: Michal Mazurek <maz@semihalf.com>
> > >
> > > Add all necessary elements for DPDK to compile and run EAL on SiFive
> > > Freedom U740 SoC which is based on SiFive U74-MC (ISA: rv64imafdc)
> > > core complex.
> > >
> > > This includes:
> > >
> > > - EAL library implementation for rv64imafdc ISA.
> > > - meson build structure for 'riscv' architecture. RTE_ARCH_RISCV define
> > >    is added for architecture identification.
> > > - xmm_t structure operation stubs as there is no vector support in the
> > >    U74 core.
> > >
> > > Compilation was tested on Ubuntu and Arch Linux using riscv64 toolchain.
> > > Clang compilation currently not supported due to issues with missing
> > > relocation relaxation.
> > >
> > > Two rte_rdtsc() schemes are provided: stable low-resolution using rdtime
> > > (default) and unstable high-resolution using rdcycle. User can override
> > > the scheme by defining RTE_RISCV_RDTSC_USE_HPM=1 during compile time of
> > > both DPDK and the application. The reasoning for this is as follows.
> > > The RISC-V ISA mandates that clock read by rdtime has to be of constant
> > > period and synchronized between all hardware threads within 1 tick
> > > (chapter 10.1 in version 20191213 of RISC-V spec).
> > > However this clock may not be of high-enough frequency for dataplane
> > > uses. I.e. on HiFive Unmatched (FU740) it is 1MHz.
> > > There is a high-resolution alternative in form of rdcycle which is
> > > clocked at the core clock frequency. The drawbacks are that it may be
> > > disabled during sleep (WFI) and its frequency might change due to DVFS.
>
> Choosing at compile time is ok for embedded but is undesireable for DPDK
> in a distribution. It sounds like the low-res is equivalent to hpet
> and the unstable is same as x86 TSC.
AFAIK, TSC has constant frequency on newer processors (see [1] for a
somewhat related Linux patch). To quote Intel
Software Developer’s Manual Volume 3, pt. 17.17.1:
  The invariant TSC will run at a constant rate in all ACPI
  P-, C-. and T-states. This is the architectural behavior moving
  forward.

> Therefore why not follow that
> precedent and do the same thing?
>
Here the situation is more akin to ARMv8 with it's low-resolution
CNTVCT and PMU based PMCCNTR. The former is always available in
userspace (EL0) while access to the latter needs to be enabled via
CSRs in kernel.
RDCYCLE on RISC-V is essentially the same as PMCCNTR, except that by
default it's enabled (governed by OpenSBI firmware - see [2]). However
it does not have the stable nature of TSC in RISC-V spec. AFAIK on ARM
this has been dealt with similarly to x86, ARMv8.6-a forces a 1GHz
frequency for CNTVCT.

So I based my implementation on the current ARM platform approach.
Given that it seems RDCYCLE will remain enabled in userspace (see
[2]), I can simplify this to use RDCYCLE if current ARM approach is
not preferred.

[1] https://patchwork.kernel.org/project/kvm/patch/20140422191200.328459410@amt.cnet/
[2] http://lists.infradead.org/pipermail/opensbi/2021-June/001219.html