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 9B82A45AD2; Mon, 7 Oct 2024 10:14:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8A4F940E39; Mon, 7 Oct 2024 10:14:35 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id 907E040E0B for ; Mon, 7 Oct 2024 10:14:34 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2fabfc06c26so35384391fa.2 for ; Mon, 07 Oct 2024 01:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728288874; x=1728893674; darn=dpdk.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=y8k1YmezoNcozHNgirPRwwumgMGzM66k7bt+Y9ysqkY=; b=FaJ/anBcX5eIcz6OdDOjJTFxxA+Fsh0yR/oL5vpATHbMiLSU1oPyS+AcF3LeOZqqSk NAKAHkzmzGzWVblaPQ7E+Owtobeg3mdvYX/oHwf/g8Phbc+W6C7qu1ebaVRh+snCM7VX I8Exg6g4GeClnM/XGPlBfq+LbufhsQRVjSItoPSZ5qmMAr9ZBxw584776KXcx2KPutmI tR5GjuBklz82f/W1YzdmPm1Ue+cB0ITwlwZNN8PKRiPw0svkGxi7DKXmiemw5hBzoAl/ tsFA7bSQ4CwDU8L1YWTktrWgYmqgRnb1AF/+v/mjWVW8fdz3qBBeqT2SxSlAkoWLWOu2 IgEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728288874; x=1728893674; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y8k1YmezoNcozHNgirPRwwumgMGzM66k7bt+Y9ysqkY=; b=Uf+wMJsJuA3im0KbJ9XngTN7ZW9Ko8sRpIvtRdAGdcwPm+ojm1GOs+6KXCAxarh6hk AWQeKoDcKsVphCNRFac0DBDvrYyDwyz9MlSKfarPdrcAS6uuX0hc4hkDMPcVeTLx+jTy L0bYVBbV4thKL7Qs73/O2/4w80DKyH0iVI4Xskes3Ccf1tkZn4BJul+cRwNHYPQ9x3mW is/zJnPSViAw4bfWFeUL0zvheWnLu/RP16zXqGFs8iKC324QKhqHuPQcAIZCC52CmWHI 1HKKY+E4km/cteq6wY7L4NU/AVhIpd0yWlmUFPVEY6eKhu8ljrA4igmlNSEsxFbpLLev Z8Pg== X-Forwarded-Encrypted: i=1; AJvYcCXkY+1c3xBTw2i0wAk4vInk58U3/ladCq0LKlijZoJzxwbyzeUNbxM2qVeRreThFX/Qbi4=@dpdk.org X-Gm-Message-State: AOJu0YxNG9eq/2lXfE8xxKUUjY6rcAB8S+KqVC6nBsioHM7XS4CfCk3j hYygiNZNc3nvvd79xOe9TIhr2MwpUBa5J/xos+FM+m7woFnOTI/o1tjAdrwiIPXZ+YETxVXaJpM zvsp4S5duBrTACjsMZDg1PCCo0Rs= X-Google-Smtp-Source: AGHT+IHlp5+eLxHBkH0V3KW81ecNGf7SF/Tu+ZPC0WIjesRfGm8oHDDrfYVmwzNRDXuvvzxj0Jva3et8qkqMpUe6NHs= X-Received: by 2002:a05:6512:3b8e:b0:537:a855:7d6f with SMTP id 2adb3069b0e04-539ab891f52mr5219568e87.34.1728288873615; Mon, 07 Oct 2024 01:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20240618174133.33457-1-daniel.gregory@bytedance.com> <20240618174133.33457-2-daniel.gregory@bytedance.com> <20240618130318.0efacceb@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F53C@smartserver.smartshare.dk> <20240619164114.GA88106@ste-uk-lab-gw> In-Reply-To: <20240619164114.GA88106@ste-uk-lab-gw> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= Date: Mon, 7 Oct 2024 10:14:22 +0200 Message-ID: Subject: Re: [PATCH 1/5] config/riscv: add flag for using Zbc extension To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Stephen Hemminger , Stanislaw Kardach , Bruce Richardson , dev@dpdk.org, Liang Ma , Punit Agrawal , Pengcheng Wang , Chunsong Feng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Jun 19, 2024 at 6:41=E2=80=AFPM Daniel Gregory wrote: > > On Wed, Jun 19, 2024 at 09:08:14AM +0200, Morten Br=C3=B8rup wrote: > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > 1/5] config/riscv: add flag for using Zbc extension > > > > > > On Tue, 18 Jun 2024 18:41:29 +0100 > > > Daniel Gregory wrote: > > > > > > > diff --git a/config/riscv/meson.build b/config/riscv/meson.build > > > > index 07d7d9da23..4bda4089bd 100644 > > > > --- a/config/riscv/meson.build > > > > +++ b/config/riscv/meson.build > > > > @@ -26,6 +26,13 @@ flags_common =3D [ > > > > # read from /proc/device-tree/cpus/timebase-frequency. This pr= operty is > > > > # guaranteed on Linux, as riscv time_init() requires it. > > > > ['RTE_RISCV_TIME_FREQ', 0], > > > > + > > > > + # Use RISC-V Carry-less multiplication extension (Zbc) for har= dware > > > > + # implementations of CRC-32C (lib/hash/rte_crc_riscv64.h), CRC= -32 and > > > CRC-16 > > > > + # (lib/net/net_crc_zbc.c). Requires intrinsics available in GC= C 14.1.0+ > > > and > > > > + # Clang 18.1.0+ > > > > + # Make sure to add '_zbc' to your target's -march below > > > > + ['RTE_RISCV_ZBC', false], > > > > ] > > > > > > Please do not add more config options via compile flags. > > > It makes it impossible for distros to ship one version. That is a problem with RISC-V in general. Since all features are "extensions" and there is no limit (up to a point) on the permutation of those, we cannot statically build the code for all extensions. Fortunately instructions tend to resolve to nops if an instruction is not present but that still increases the code size for no benefit on platforms without a given extension. > > > > > > Instead, detect at compile or runtime > > > > Build time detection is not possible for cross builds. > > > > How about build time detection based on the target's configured > instruction set (either specified by cross-file or passed in through > -Dinstruction_set)? We could have a map from extensions present in the > ISA string to compile flags that should be enabled. > > I suggested this whilst discussing a previous patch adding support for > the Zawrs extension, but haven't heard back from Stanis=C5=82aw yet: > https://lore.kernel.org/dpdk-dev/20240520094854.GA3672529@ste-uk-lab-gw/ I think we already have 1 case of a cross compile config: https://git.dpdk.org/dpdk/tree/config/riscv/riscv64_sifive_u740_linux_gcc. This could serve as a stop gap before runtime detection is sorted out. I would prefer the static option to rather list all the hardware platforms explicitly. This way we will support existing platforms, not some RISC-V vendor plans. Maybe at some point the extension mess gets fixed in the arch. > > As for runtime detection, newer kernel versions have a hardware probing > interface for detecting the presence of extensions, support could be > added to rte_cpuflags.c? > https://docs.kernel.org/arch/riscv/hwprobe.html > > In combination, distros on newer kernels could ship a version that has > these optimisations baked in that falls back to a generic implementation > when the extension is detected to not be present, and systems without > the latest GCC/Clang can still compile by specifying a target ISA that > doesn't include "_zbc". hwprobe sounds like a good idea, although the key name for extensions (RISCV_HWPROBE_KEY_IMA_EXT_0) suggests that there will be more (it's 64bit and we already have 46 bits taken). That I wonder what options we have to keep the performance characteristics of the code. We either need to live-patch the code (which is problematic for userspace processes) or resort to some .so or a driver-like model. Neither option sounds very appealing.