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 377DA440F4; Tue, 28 May 2024 18:03:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF986402E4; Tue, 28 May 2024 18:03:31 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id CDE2B4025D for ; Tue, 28 May 2024 18:03:29 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7B6E7438B for ; Tue, 28 May 2024 18:03:29 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 6EE664400; Tue, 28 May 2024 18:03:29 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 1930241FF; Tue, 28 May 2024 18:03:27 +0200 (CEST) Message-ID: <8d51d44d-06b9-4c62-be51-35e90936d2f4@lysator.liu.se> Date: Tue, 28 May 2024 18:03:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] eal: provide option to use compiler memcpy instead of RTE To: Stephen Hemminger Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= 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> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240528075936.2110c31c@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-05-28 16:59, Stephen Hemminger wrote: > On Tue, 28 May 2024 10:19:15 +0200 > Mattias Rönnblom wrote: > >>> >> >> 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 next >> release. > > 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. If/when rte_memcpy.h is just a tiny memcpy() wrapper, the maintenance burden is pretty much eliminated. Keeping it around will allow for older applications to compile against newer DPDK version. You can always discourage its use in the API documentation. Also, hopefully, some day, we will have a non-temporal memcpy(), and those functions needs a home.