From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 65F1E44087; Tue, 21 May 2024 13:42:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC8B1402BA; Tue, 21 May 2024 13:42:09 +0200 (CEST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by mails.dpdk.org (Postfix) with ESMTP id 2C21F400EF for ; Mon, 20 May 2024 17:43:58 +0200 (CEST) Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-34db6a29a1eso2151749f8f.1 for ; Mon, 20 May 2024 08:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1716219838; x=1716824638; darn=dpdk.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=NPyBEeYRzMiO9QqpkDjOxm2y/DHhQ7YxL1TRy9dPmPE=; b=Vui+agOOu+OG3aDBy3ktV48Lbrvl2iXqebP6sksW9EZMD5w47Vh0kn94j1Yw2S+AHX hPwdt19Iv8eGpqRUBYipqged/w6YIb7naIsNGdeUPVGAoYIwZ72HjZtfdCNaB0vCbNHx hLX0uAFVqELtjQMusXQruoIcjUhslCoN2ek6HpU7pSF3aXbZi5ICGoL6byaZtlc9uL1y xGWaO+4NOrVWrsk6eqrnb5x8Rt8JD/Hm/vovkIGQM/SOurvjO2L8WjYVTMRRRyJMA9/B TUgSP8O1Or2uX22w35PGQ80apWqz0we2ayLTTphVSpjhKc/ScvdKQNNhqHyOwIsp2uK7 oDaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716219838; x=1716824638; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=NPyBEeYRzMiO9QqpkDjOxm2y/DHhQ7YxL1TRy9dPmPE=; b=YuwpsgwPXnn0yhevyOAkMTWy7DxCtl1I8EWJNR7M1D8bInL8JhMlMV2KAfzhpBpEvx vXNVAPTTk955QgouMznKIl269FZBSLEY09pBnGsArSOFVFWkR4cHXe1vb7hHr8IMVmJV O7zAq46PU6/rRDoCHcbtG9og0q4bLN1NIwcqQPu65Sqy3IZDXwzLLesX14ZdKtOy/hU1 fBhU5KcLs554Q2O56n51rcJiAT+wI2OLMK/Zajb//vbtiggFPJ8OOzaW2oESWu0+/ZE/ 0VpwNPrDmvno8lW3plE7EHpAq6uRYG9itPE5q32Hwc/eQ9P4DXfUtC2POZxkqT2Kv1Hp vX7w== X-Forwarded-Encrypted: i=1; AJvYcCXmsPQOzZ/nwr5SDFlvtgC8b4C6jYqKIkZHmyg7/+xAXxb4/opPBblvia/ux4MGa2iOl+YUqk0ojFH4XVw= X-Gm-Message-State: AOJu0Yz8XT/qTxQqsaUZETvHncGYT7nwJhq3mVrH399fsvwec+f0SOyE SK8GKuxOAkJGeOxNaBcDA+hymaqtfoLqHgv5JhNnzCFY3rerCfpYCO6kaiwhf52M9Zs4LpySIAq n X-Google-Smtp-Source: AGHT+IGqsuTJn0+wV6h5xAW8SKkkGJUyiD/RUYLsaxtEevKhKI76Mpdwd+V1fPey0RnzMWTXhBI7Tg== X-Received: by 2002:adf:e2d2:0:b0:34d:8ccf:2c10 with SMTP id ffacd0b85a97d-3504a62ff7dmr19577031f8f.10.1716219837785; Mon, 20 May 2024 08:43:57 -0700 (PDT) Received: from localhost ([95.148.15.92]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3502bbbbff7sm29391451f8f.101.2024.05.20.08.43.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 08:43:57 -0700 (PDT) From: Punit Agrawal To: =?utf-8?Q?Stanis=C5=82aw?= Kardach Cc: Daniel Gregory , Bruce Richardson , dev@dpdk.org, Liang Ma , Punit Agrawal Subject: Re: [External] Re: [RFC PATCH] eal/riscv: add support for zawrs extension In-Reply-To: (=?utf-8?Q?=22Stanis=C5=82aw?= Kardach"'s message of "Sun, 12 May 2024 09:10:49 +0200") References: <20240502144149.66446-1-daniel.gregory@bytedance.com> Date: Mon, 20 May 2024 16:43:56 +0100 Message-ID: <87msoko5dv.fsf@bytedance.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 21 May 2024 13:42:08 +0200 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Stanis=C5=82aw Kardach writes: > On Thu, May 2, 2024 at 4:44=E2=80=AFPM Daniel Gregory > wrote: >> >> The zawrs extension adds a pair of instructions that stall a core until >> a memory location is written to. This patch uses one of them to >> implement RISCV-specific versions of the rte_wait_until_equal_* >> functions. This is potentially more energy efficient than the default >> implementation that uses rte_pause/Zihintpause. >> >> The technique works as follows: >> >> * Create a reservation set containing the address we want to wait on >> using an atomic load (lr.dw) >> * Call wrs.nto - this blocks until the reservation set is invalidated by >> someone else writing to that address >> * Execution can also resume arbitrarily, so we still need to check >> whether a change occurred and loop if not >> >> Due to RISC-V atomics only supporting naturally aligned word (32 bit) >> and double word (64 bit) loads, I've used pointer rounding and bit >> shifting to implement waiting on 16-bit values. >> >> This new functionality is controlled by a Meson flag that is disabled by >> default. >> >> Signed-off-by: Daniel Gregory >> Suggested-by: Punit Agrawal >> --- >> >> Posting as an RFC to get early feedback and enable testing by others >> with Zawrs-enabled hardware. Whilst I have been able to test it compiles >> & passes tests using QEMU, I am waiting on some Zawrs-enabled hardware >> to become available before I carry out performance tests. >> >> Nonetheless, I would be glad to hear any feedback on the general >> approach. Thanks, Daniel >> >> config/riscv/meson.build | 5 ++ >> lib/eal/riscv/include/rte_pause.h | 139 ++++++++++++++++++++++++++++++ >> 2 files changed, 144 insertions(+) >> >> 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 =3D [ >> # read from /proc/device-tree/cpus/timebase-frequency. This propert= y 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? > Or perhaps add machine detection logic based either on the "riscv,isa" > cpu@0 property in the DT or RHCT ACPI table? Compile time feature detection doesn't add a lot of benefit - it doesn't work in cross builds environments - which is the common way things are built for RISC-V at the moment. Also it doesn't work for distros where a single build is used across a broad set of machines. > Or add perhaps some other way we could specify the extension list > suffix for -march? Making it easier to specify the required extensions during the build does make sense. Though this is an orthogonal change and is better done in follow-on patches. [...]