From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6C29AA00BE; Mon, 16 May 2022 10:00:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 533F840A7A; Mon, 16 May 2022 10:00:55 +0200 (CEST) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by mails.dpdk.org (Postfix) with ESMTP id 4DC2340A79 for <dev@dpdk.org>; Mon, 16 May 2022 10:00:54 +0200 (CEST) Received: by mail-lj1-f171.google.com with SMTP id bx33so17081904ljb.12 for <dev@dpdk.org>; Mon, 16 May 2022 01:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jTDLk7wpkSm7oXO/exL3PDF7MKUEjiPMVRoiqgVADuY=; b=o6A6zwAuera0yTDl5S5m+8WObklG9RTyv4BQwKGTCvsITUm+ESs+K2bVN/IpoXVRnU mu/aurrPmvg7Knm3oAvdOUqmtpi0G2oAzXcVF//RXM//rNuqNtgeH39IgFs9A622CL5y ttUmRbFDLVVp5LUyVQRlnr5hFzj2SdIfXqY35rwsiB3mvNwLyPkFW9hOX/bJsZebeHYG Rm9ctjmEoy9ej+0hx4CxmnOmePC5kYXAVSZKsyMzWxi8lH59HS0EYrAxkrMp/ZIEDd+0 8W0jz/hNXyt56Bme4fGjuMZp8wmAGkkfuhpINvIvbfLuc2cMLj70g3Sr4E2HEVFu3Gtp tecQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jTDLk7wpkSm7oXO/exL3PDF7MKUEjiPMVRoiqgVADuY=; b=1NfGNwtgL2D6Op73M0L5AO2Ey8DYvHyT2xgwIUoXbODOu/SzVYHGpTRyoEfMdVnLHM N78/5gvUnERhgwkxMlZ6kNOf4bCfdW69PWdgAAANYI2+CFpN/0SlpeFOnx/mE7TXfTD2 IXUNLCJ1cdboCUxPqBk4i/f4ANMNocfIla5nDGEXc7NycxcKn+t5l30eMHums+c7NKh8 2QPuUqpgqvy8UMh8tyndfuXCmxIe5UmlSumXdr2iuHSJ4ItBG+MqzFhP9QmHnIg0O+h4 NznipwSFEm9g4voKfdzzX3fv/Nnl6nByy0W8XEKE1zghXCRcpzHjsfZMPTiTHBFeiBwc dQdA== X-Gm-Message-State: AOAM533x7CTpofFUbUYtvIKycUIKrvbixNd6STF8e2kFVy7FkJS67gN+ SKx+efwvWVyessjDMa77hs8qCK/JqRShm1YqYBcSuQ== X-Google-Smtp-Source: ABdhPJz273V5ONyh9fLL+32tboHwwjqjAaLMW19MZeaVHVr0bhus8I+ZOBTrbscJfss2OT3w/B47QN6+P+uWLc4C8nc= X-Received: by 2002:a2e:9188:0:b0:24f:1a0d:6bbd with SMTP id f8-20020a2e9188000000b0024f1a0d6bbdmr10363739ljg.226.1652688053637; Mon, 16 May 2022 01:00:53 -0700 (PDT) MIME-Version: 1.0 References: <20220510150759.525434-1-kda@semihalf.com> <20220510154849.530872-1-kda@semihalf.com> <20220510154849.530872-2-kda@semihalf.com> <7bc97240-10c7-c437-9f31-b97dc2b418c6@canonical.com> <20220513083700.2b073882@hermes.local> In-Reply-To: <20220513083700.2b073882@hermes.local> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= <kda@semihalf.com> Date: Mon, 16 May 2022 10:00:17 +0200 Message-ID: <CALVGJW+Dhxw6KMSSXJ3u5+D44JVvC4EbMJSx0BqTHQuO870icg@mail.gmail.com> Subject: Re: [PATCH v3 1/8] eal: add initial support for RISC-V architecture To: Stephen Hemminger <stephen@networkplumber.org> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>, Thomas Monjalon <thomas@monjalon.net>, Michal Mazurek <maz@semihalf.com>, dev <dev@dpdk.org>, Frank Zhao <Frank.Zhao@starfivetech.com>, Sam Grove <sam.grove@sifive.com>, Marcin Wojtas <mw@semihalf.com>, upstream@semihalf.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 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 defi= ne > > > is added for architecture identification. > > > - xmm_t structure operation stubs as there is no vector support in th= e > > > U74 core. > > > > > > Compilation was tested on Ubuntu and Arch Linux using riscv64 toolcha= in. > > > Clang compilation currently not supported due to issues with missing > > > relocation relaxation. > > > > > > Two rte_rdtsc() schemes are provided: stable low-resolution using rdt= ime > > > (default) and unstable high-resolution using rdcycle. User can overri= de > > > the scheme by defining RTE_RISCV_RDTSC_USE_HPM=3D1 during compile tim= e 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 consta= nt > > > 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 DVF= S. > > 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=E2=80=99s 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