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 CC1B1440DE; Mon, 27 May 2024 08:06:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 914DE402BD; Mon, 27 May 2024 08:06:41 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 4BC1F402BC for ; Mon, 27 May 2024 08:06:40 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 585241D593 for ; Mon, 27 May 2024 08:06:38 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 4CD171D4C1; Mon, 27 May 2024 08:06:38 +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 104751D526; Mon, 27 May 2024 08:06:36 +0200 (CEST) Message-ID: Date: Mon, 27 May 2024 08:06:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 00/32] replace use of rte_memcpy() with fixed size To: Stephen Hemminger Cc: dev@dpdk.org References: <20240403163432.437275-1-stephen@networkplumber.org> <20240522033009.143100-1-stephen@networkplumber.org> <20240526163232.171ca90d@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240526163232.171ca90d@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-27 01:32, Stephen Hemminger wrote: > On Sun, 26 May 2024 16:51:52 +0200 > Mattias Rönnblom wrote: > >>> This does not change the resulting binary on almost all architectures >>> because x86 version of intrisics and glibc are the same, and >>> other architectures were using __builtin_constant_p(). >>> >>> The main benefit is that analysis tools like fortify, Coverity, and ASAN >>> analyzers can check these memcpy's. A recent example is that >>> on Ubuntu 22.04 detected undefined use of memcpy such as: >>> memcpy(dst, NULL, 0) >>> >> >> Would it be possible to instead have a build mode where rte_memcpy() is >> *always* delegating to memcpy(), and run these tools on that configuration? >> >> It seems easier to just always using rte_memcpy() in DPDK code, then let >> the platform (not the programmer) choose whatever is most appropriate. > > I would prefer that rte_memcpy be laid to rest and go away. Sounds good, but is this piecemeal approach the way to do it. Why ask DPDK programmers to memorize rules about when to use memcpy() and when not to, when that can be coded into the rte_memcpy() implementation. Worst case, when people have learned those rules, we'll change them. "Use rte_memcpy() only for large copies," or whatever it might be. Use rte_memcpy() across the board until memcpy() is a complete replacement, for every use case, for every CPU/compiler/OS. Applications using DPDK will benefit from any heuristics encoded into rte_memcpy.h. The won't run coccinelle script. > It never had a reason to be there. Sure, it did. Historically it has had better performance, up to at least fairly recently that seemed still be the case. I've patched DPDK to replace rte_memcpy() with memcpy() several times, and run with real-world apps. The result is always the same. The compiler is in a better position than DPDK to implement memcpy(), so eventually the compiler will win.