From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1DB4944132;
	Sun,  2 Jun 2024 13:30:17 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id E77B240150;
	Sun,  2 Jun 2024 13:30:16 +0200 (CEST)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3])
 by mails.dpdk.org (Postfix) with ESMTP id 8210F40042
 for <dev@dpdk.org>; Sun,  2 Jun 2024 13:30:15 +0200 (CEST)
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
 by mail.lysator.liu.se (Postfix) with ESMTP id BE2B918C7B
 for <dev@dpdk.org>; Sun,  2 Jun 2024 13:30:14 +0200 (CEST)
Received: by mail.lysator.liu.se (Postfix, from userid 1004)
 id 9FBB418C7A; Sun,  2 Jun 2024 13:30:14 +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 C77FE18CC6;
 Sun,  2 Jun 2024 13:30:10 +0200 (CEST)
Message-ID: <71dc3992-2a4e-4ef7-be7c-dd1a186dc739@lysator.liu.se>
Date: Sun, 2 Jun 2024 13:30:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] eal: provide option to use compiler memcpy instead of RTE
To: Stephen Hemminger <stephen@networkplumber.org>,
 =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>
Cc: dev@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
References: <20240527111151.188607-1-mattias.ronnblom@ericsson.com>
 <20240529145634.33bbb439@hermes.local>
Content-Language: en-US
From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <hofors@lysator.liu.se>
In-Reply-To: <20240529145634.33bbb439@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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On 2024-05-29 23:56, Stephen Hemminger wrote:
> On Mon, 27 May 2024 13:11:51 +0200
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
> 
>> #ifdef RTE_USE_CC_MEMCPY
>> +static inline void
>> +rte_mov16(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 16);
>> +}
>> +
>> +static inline void
>> +rte_mov32(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 32);
>> +}
>> +
>> +static inline void
>> +rte_mov48(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 48);
>> +}
>> +
>> +static inline void
>> +rte_mov64(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 64);
>> +}
>> +
>> +static inline void
>> +rte_mov128(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 128);
>> +}
>> +
>> +static inline void
>> +rte_mov256(uint8_t *dst, const uint8_t *src)
>> +{
>> +	memcpy(dst, src, 256);
>> +}
>> +
>> +static inline void *
>> +rte_memcpy(void *dst, const void *src, size_t n)
>> +{
>> +	return memcpy(dst, src, n);
>> +}
>> +#endif /* RTE_USE_CC_MEMCPY */
>> +
>> +#ifdef __cplusplus
>> +}
>> +#endif
> 
> You may need to make these macros to fully engage the checking
> options of GCC, fortify, coverity etc. Not sure if all the tools
> are smart enough to see through an inline.

At least GCC is, provided you compile with optimization enabled. That 
goes for both overlapping memcpy() warning and static buffer overruns.

clang doesn't warn about overlapping memcpy() and fails to follow 
function calls, even with optimization enabled, seemingly. Same for ICX.

Static analysis tools that can't beat the compiler seems like they would 
be of limited use.

With macros you'll lose the type checking, which in the rte_memcpy() 
case doesn't matter, but rte_mov*() case it does.

I'll sure it break something to change this to macros, although it would 
be good if clang would also generate a warning (for application code 
using <rte_memcpy.h>).