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 1548945AAE; Fri, 4 Oct 2024 14:07:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C839E40E5E; Fri, 4 Oct 2024 14:07:21 +0200 (CEST) Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) by mails.dpdk.org (Postfix) with ESMTP id B92DB4027F for ; Fri, 4 Oct 2024 14:07:20 +0200 (CEST) Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3D1E811402D0; Fri, 4 Oct 2024 08:07:20 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Fri, 04 Oct 2024 08:07:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1728043640; x=1728130040; bh=M4Fq8L//H1Nxg/ulsIG3ZK5YzIvS5rdBf0Y4/vSImpU=; b= Ncs70gQvAar/W6WZ6A4vIeaQjxptYqiVjM0vHxZ330rmxXlVm4SCvFwIYL0htDUa NkMQMU2epnF0jgqSfSUbffwc2+QMM3Re8kuNoMxd34y0n/M0ZZsLgUm/v45U1j8Y C15s23UIMeAIs/D7pfZTkQUh97FSSPzr15nvcstcKRFfFWGZPs4Es1Qe5BPChzdB 0KZ/bTcmoxPWLgViwMgIEhIUit/a5xqyCbgUTGDJrdahN7SOm+H2VfE+jKs45Ovl PYVeQHIiW/V3k+50JRydr7iQwQF7+hdssUhO2hOmdaU/1f7++vHg/yJ6Wm7/Io5e ugEnAOO8vsnS408EU7Q55g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1728043640; x= 1728130040; bh=M4Fq8L//H1Nxg/ulsIG3ZK5YzIvS5rdBf0Y4/vSImpU=; b=o 2HZiE4nBHTmP5fIpeQwzbzdT//2hFF7iAWr5vF+KCfNF3WsvNGPRllanvGaJtUs9 kzuxvARlRvE5glpj9BZVKsJ+QgRxVkChouimwvKAa8qz/TTuDTXGZlUtLSSwyZLB ntc1ynHkUaGPwjziPXz/LAECXbePLF+Ywk9y8lbSONvrC9qtL+Hal+DzTDz31BUx gCn6vi2iTWeQOq61py19YLORxtOtgPbkyYAAcMqp02vFYKKy4Z2+raP+pbSdgvKF rAWACuCZ/LYIRo2sO/9pYElDggydTLhwlU8riiWbfVEbVFOaBOwP783jOHlu/tXp q+QXPfO8ZfvVDMuHS9j4w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddvfedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedt heevtdekiedvueeuvdeiuddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhn sggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehhohhfoh hrsheslhihshgrthhorhdrlhhiuhdrshgvpdhrtghpthhtohepmhgrthhtihgrshdrrhho nhhnsghlohhmsegvrhhitghsshhonhdrtghomhdprhgtphhtthhopeguvghvseguphgukh drohhrghdprhgtphhtthhopehmsgesshhmrghrthhshhgrrhgvshihshhtvghmshdrtgho mhdprhgtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrhdrohhrgh dprhgtphhtthhopehpsghhrghgrghvrghtuhhlrgesmhgrrhhvvghllhdrtghomhdprhgt phhtthhopegsrhhutggvrdhrihgthhgrrhgushhonhesihhnthgvlhdrtghomhdprhgtph htthhopegurghvihgurdhmrghrtghhrghnugesrhgvughhrghtrdgtohhm X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 4 Oct 2024 08:07:18 -0400 (EDT) From: Thomas Monjalon To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1cA==?= , Stephen Hemminger , Pavan Nikhilesh , Bruce Richardson , David Marchand Subject: Re: [PATCH v6 5/7] eal: provide option to use compiler memcpy instead of RTE Date: Fri, 04 Oct 2024 14:07:16 +0200 Message-ID: <3842096.MHq7AAxBmi@thomas> In-Reply-To: References: <20240724075357.546248-2-mattias.ronnblom@ericsson.com> <8e63fd80-2ab0-4afe-94e8-ce3277338fdf@lysator.liu.se> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 04/10/2024 11:54, David Marchand: > On Fri, Oct 4, 2024 at 11:21=E2=80=AFAM Mattias R=C3=B6nnblom wrote: > > > - Now, looking at what was available for arches so far in DPDK: > > > * ARM was relying by default on compiler implementation, with specific > > > implementations for ARM32 and ARM64 available (see for more details > > > below) =3D> possible values (default first) RTE_USE_CC_MEMCPY =3D tru= e / > > > false > > > * loongarch was relying on compiler implementation, with no specific > > > implementations, =3D> RTE_USE_CC_MEMCPY =3D true > > > * ppc was relying on arch specific implementation, =3D> RTE_USE_CC_ME= MCPY =3D false > > > * risc was relying on compiler implementation, with no specific > > > implementations, =3D> RTE_USE_CC_MEMCPY =3D true > > > * x86 was relying on arch specific implementation, =3D> RTE_USE_CC_ME= MCPY =3D false > > > > > > We can't get a unified default value for a meson option and keep > > > compat for all arches (except maybe introduce a "auto" value). > > > > > > Plus, disabling RTE_USE_CC_MEMCPY on loongarch and risc makes no > > > sense, as there was never a specific implementation. > > > > > > My suggestion is to drop the meson option and instead just set > > > RTE_USE_CC_MEMCPY in config/$arch/meson.build. > > > Testers / interested users may edit config/$arch/meson.build on their= own. > > > > > > > So we've gone from... > > > > "Eliminate DPDK custom per-arch memcpy altogether" > > to > > "Keep custom memcpy, but make cc memcpy the default" > > to > > "Keep custom memcpy as the default, but make cc memcpy a build option" > > to > > "Keep custom memcpy as the default, and have the user modify some > > obscure build file to use cc memcpy" > > > > I seems like the natural next step is just > > > > "Keep the custom memcpy. Period." >=20 > Well, the current implementation has holes, that I tried to list so we > can move forward. >=20 > About adding a meson option, we try to have as less of them as > possible to reduce complexity. > And this is why an obscure option is probably the best so that > performance tests can be run with the compiler, without breaking > existing users. >=20 >=20 > If what I replied is irrelevant to others, well, I will let others > review _*in* *depth*_ and Thomas can merge the series. No I won't merge it as is. Mattias, please take a breath and think again about the comments David did. We support the move to CC memcpy. The CC memcpy was already used for some arches. We agree having it as an option for all arches is a good step forward. Having a compilation define to do some benchmark on any arch is good. When it will become good enough, we will enable it on more arches by defaul= t. I think it looks very reasonable, we just ask you to prepare the future without breaking anything for now. Then it will be very simple patches to decide enabling it more. And because we want CC memcpy to become the only option, it does not make sense to introduce a new option for the user.