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 9FE0F440B7; Fri, 31 May 2024 18:50:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 86F4642DC0; Fri, 31 May 2024 18:50:54 +0200 (CEST) Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.47]) by mails.dpdk.org (Postfix) with ESMTP id 1F4E1402D0 for ; Fri, 31 May 2024 18:50:53 +0200 (CEST) Received: by mail-oo1-f47.google.com with SMTP id 006d021491bc7-5b98f49e27bso934076eaf.2 for ; Fri, 31 May 2024 09:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1717174252; x=1717779052; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=n7uxDVD4CoeS3hVXEYlcieogcKxeN5HlypNcHelhhrQ=; b=OInqu1LBwIvCKNSysxcTKLdlejj9kQq4vvENxe78mOgYIslc9GJqDJp6DRG0rLkwVu zEGyMFkf8KoBj/I0/PrCZyLILjvZacNQeHNGLIhvKMIchx80ml7uPfxg2VSloIOpdB7Q S5EwoO/ym+HCDLA9O3G5OT6VPsX6Cm591eEh1QTaQPa60WnBoYApks1zkNLKK+eJoTij Hi3OXaVSRExxpWNaRpY35HqiphWBTj0eYuYn0hzpTdKERkZBYZquQQJuw4j5P/pX3qKB Ynlj3ikJh+TFEeIHA4/W1X3VPiamxtYPNsa1azYNoJ68WO2Ai/A/4loPbrPCqRN/IcSb 2nYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717174252; x=1717779052; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n7uxDVD4CoeS3hVXEYlcieogcKxeN5HlypNcHelhhrQ=; b=JOiDd8Jq6oXyKlpnMNNq4Mk0kxRqy9eUPm0O2xkQgFBngyET64GE/mgURMDOfzh9yt KF/iJGNO0c7g2Y8/5ChrzYWWdYSs18SCdGNaVs4y55p6slKELgGNisZGbgMS2wBuN/sf wxZDnUwxpNHpY8RUU5gqIUcaXhmbW9FhACcO71URmSmEfXj9c8/QR+uRKAjuYB8HYiie P1K/a5LCDerx/kjTbKHSRlDQvDBZxJ1pbj/3h6TSkDCdcaBj8PXWmimi7vsK5D4qig9n 3M73JxnMU+TpaXsQ/F80GFB2sOohCS5LSFQyvWr5qOz7T9rTK3TIVtkbGzNRf2kPOod0 GCcw== X-Forwarded-Encrypted: i=1; AJvYcCVuDtQ22xpre6eLekUC4ZQWhE1A9YQIN34//3R1zCu1x5vtW8oudam4wEunnK9srkDwUdOtPDp0ftCtPr8= X-Gm-Message-State: AOJu0Yx6MCbOXNdVmxU72QV8Hq7LCE4T6xuy0YBjkjlDL5F9k69rDOR/ gK6TnflYLzp79mcWx9yVqg9gct6+jrUJKfj/QVyhA6rZ3D3BhSmu0CWV5iaifDpqTFZVTtAfapF A X-Google-Smtp-Source: AGHT+IHqrFE72LQ9R70Ok4uRnHwvwnjdWLyl3sNHIGj3thZUMDailznTKn6e6v8xjZZQiboXB9gjiw== X-Received: by 2002:a05:6358:11:b0:186:2ac7:316c with SMTP id e5c5f4694b2df-19b48fac294mr243532055d.20.1717174252188; Fri, 31 May 2024 09:50:52 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-6c354d7fc4dsm1477103a12.25.2024.05.31.09.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 09:50:52 -0700 (PDT) Date: Fri, 31 May 2024 09:50:50 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Bruce Richardson , Mattias =?UTF-8?B?UsO2?= =?UTF-8?B?bm5ibG9t?= , dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [RFC v2] eal: provide option to use compiler memcpy instead of RTE Message-ID: <20240531095050.7bae58b0@hermes.local> In-Reply-To: References: <20240527111151.188607-1-mattias.ronnblom@ericsson.com> <20240528074354.190779-1-mattias.ronnblom@ericsson.com> <738e376c-c5b6-44dc-ad51-00f40d2ea6b5@lysator.liu.se> <20240528075936.2110c31c@hermes.local> MIME-Version: 1.0 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 Fri, 31 May 2024 07:19:41 +0200 Mattias R=C3=B6nnblom wrote: > On 2024-05-28 17:09, Bruce Richardson wrote: > > On Tue, May 28, 2024 at 07:59:36AM -0700, Stephen Hemminger wrote: =20 > >> On Tue, 28 May 2024 10:19:15 +0200 > >> Mattias R=C3=B6nnblom wrote: > >> =20 > >>>> =20 > >>> > >>> I've tested this patch some with DSW micro benchmarks, and the result= is > >>> a 2.5% reduction of the DSW+testapp overhead with cc/libc memcpy. GCC= 11.4. > >>> > >>> We've also run characteristic test suite of a large, real world app. > >>> Here, we saw no effect. GCC 10.5. > >>> > >>> x86_64 in both cases (Skylake and Raptor Lake). > >>> > >>> Last time we did the same, there were a noticeable performance > >>> degradation in both the above cases. > >>> > >>> This is not a lot of data points, but I think it we should consider > >>> making the custom RTE memcpy() implementations optional in the next > >>> release, and if no-one complains, remove the implementations in the n= ext > >>> release. =20 > >> > >> Lets go farther. > >> > >> 1. Announce that rte_memcpy will be marked deprecated in 24.11 release > >> > >> 2. In 24.11 do a global replace of rte_memcpy on the tree. > >> And mark rte_memcpy as deprecated. > >> > >> 3. In 25.11 it can go away. =20 > >=20 > > While I'd like us to be able to do so, I believe that to be premature. = We > > need to see where/if there are regressions first, and see about fixing > > them. > >=20 > > /Bruce =20 >=20 > Should I turn this RFC into a PATCH? >=20 > Is use_cc_memcpy a good name for the configuration parameter? >=20 I did a slightly more direct test and found a couple of things: 1. Ena driver is redefining memcpy as rte_memcpy, this should be removed= and should have been blocked during code review. 2. A couple of drivers are implicitly expecting simd vector routines to = be available. This works because rte_memcpy.h includes rte_vect.h. The fix is to h= ave these places include rte_vect.h