On Fri, May 13, 2022 at 5:37 PM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Fri, 13 May 2022 08:50:34 +0200 > Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > > On 5/10/22 17:48, Stanislaw Kardach wrote: > > > From: Michal Mazurek <m...@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.328459...@amt.cnet/ [2] http://lists.infradead.org/pipermail/opensbi/2021-June/001219.html
