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 1798945A73; Tue, 8 Oct 2024 07:52:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8551402E4; Tue, 8 Oct 2024 07:52:55 +0200 (CEST) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by mails.dpdk.org (Postfix) with ESMTP id 8C47A4025D for ; Tue, 8 Oct 2024 07:52:54 +0200 (CEST) Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5c42e7adbddso7106630a12.2 for ; Mon, 07 Oct 2024 22:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728366774; x=1728971574; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+FtXR/IfYrjQMCdkMqwqqvAN7ehZY3l1+PMzNogG0rM=; b=Wzbzub59Su+DLJqkALeqhkppUCIzpAVOSJBdvNUF75VNWyDtxdP2sVWJeTveNUdfzg eXHvxLYOEITREVn9YmM8iFe5bq7gYf5lGH882n3r9AB9d31GGtO8cQGR6pYtLzt1oWWm NMWVQtLqSMffx9WhSWY2t8jBZGuAkHAZca79E1GFlHZta71Ttxf1Gjq0VK3SHOsMASGW G3mayqXsJjWme+2BfJ4doo12xQkx/O3znlyilarVCs1aiUsdPUpROfZVnhG6ZlPTxODv UwmuKvvcA0FDM/UPWS6OXfBsOBy/ZRYxh/xIFT0S5D4T+0G8iHO7+dTcAHxRhqStLEy1 qYCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728366774; x=1728971574; h=content-transfer-encoding:cc: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=+FtXR/IfYrjQMCdkMqwqqvAN7ehZY3l1+PMzNogG0rM=; b=VYXzrie0CouSh7xuFJG4fmQQ27Ebk9iN/s0BAaBgHk5vjVLzhZkcX+fkhr7T6sz0jL n5I45b8x2CKiXGZ1U3zlPE63lZoUsb0jTYSkrX/Qy5wBDm1hdUI3eSx4rLhjYO+Gl6+p o+niPMGKqHNoIye8DT4UHj182bARPkDct2yL8RXgxuxctCup7yS2w0A/Be1fj4zCRGLp RRdOD2bCdeN5rhr6cfmG4dEh5zYpxN/vIq6LbOhiYIj5hQgP1XDCjpUohffRQKSEgysv trBYheRuYrFGmorZLGo408l/dfqTGwCLUDLFvH+dLwA/XFj40zI8JjaTpPDYM8N9yN58 POJQ== X-Forwarded-Encrypted: i=1; AJvYcCXkz/Sc4QI8qqOOG4z45d3N+c4R19Sll8KxgnuQQuuWYrYC1QixmfUMT+BrKym5nPECC5Q=@dpdk.org X-Gm-Message-State: AOJu0YzXzaDkv7SIvfNE1gJVlGy84Zm1oUHkdCHPePL82mZCcy3KSumW mojnlLDDEpEgQcR5l0qLBGmbhjjpGosUKLQ03JR/4aSx3xOH6lIGBKYUcyS8g55JCYyThHIAOp9 S4TnYj2Xu17STzcE7r+VFzNaMBzcRkXDg X-Google-Smtp-Source: AGHT+IEnzRJ9bkFkmnMyeJsAByjVKGENNJyYV4eAbQeJvr4HukmZKgOiT55uvE/U6dzay4Vg3g/VwuCoqaiYugsh+dM= X-Received: by 2002:a17:907:7e83:b0:a99:5773:3612 with SMTP id a640c23a62f3a-a99577342e7mr578532866b.36.1728366773883; Mon, 07 Oct 2024 22:52:53 -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> <20241007082019.55d64b3b@hermes.local> In-Reply-To: <20241007082019.55d64b3b@hermes.local> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= Date: Tue, 8 Oct 2024 07:52:42 +0200 Message-ID: Subject: Re: [PATCH 1/5] config/riscv: add flag for using Zbc extension To: Stephen Hemminger Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , 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 Mon, Oct 7, 2024 at 5:20=E2=80=AFPM Stephen Hemminger wrote: > > On Mon, 7 Oct 2024 10:14:22 +0200 > Stanis=C5=82aw Kardach wrote: > > > > > > > > > > > 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. > > X86 already has the cpu feature flag infrastructure, why not use similar > mechanism on RiscV? We can and some further patches I've seen on the list implemented that. However if that has to be applied in basic intrinsics like rte_prefetch() which means we'd have to pay a conditional or an indirect call. It'd be best to test it on a real dataplane platform to which I don't have access.