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 EE62A43C41; Sat, 2 Mar 2024 18:02:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9EDDA4025C; Sat, 2 Mar 2024 18:02:12 +0100 (CET) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by mails.dpdk.org (Postfix) with ESMTP id E8C70400D5 for ; Sat, 2 Mar 2024 18:02:10 +0100 (CET) Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-6e5dddd3b95so674132b3a.1 for ; Sat, 02 Mar 2024 09:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1709398930; x=1710003730; 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=rDytTfyz78mU43sZhryFqL8oFy1iMqMdr1FhRRA/WJY=; b=k+fvF0wMNIor8VQy5Va5yeRiHVr+hN3xHR5FNlD5LW97S2st4r5kwxexm/t4xz99Lh gODErNjHCmf07aIpQx17PgrH2ehso70wnUlXX/ULqG72n5/iVmqooyXlM7V9VfukZ0EQ FYidU45EDqKCFJIjCdBdnnfCKeczpJdRD5MKlPKlBZyG/CUe7STbCNH9wZKIFDU8eH4R umF4L6Pcfza38h1YBfIMkT8Fv/SeuVt9ZLJ1HyHnBnKu8taWbchHFlne9pt1rdeiEYT/ +fR0BRoDW2b9y3HRbWc2wEN9Xw0t53kuJn/4FSPzuEEGz/guVQxJgKCB83IxZBNfq0gx 2Ctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709398930; x=1710003730; 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=rDytTfyz78mU43sZhryFqL8oFy1iMqMdr1FhRRA/WJY=; b=S3uivAMWFr0T9v8zqjIxQY6ZpuJDF09JmMC6P83kmTt+7m1grZJBp637N9BcfnYo// 982EFbfDhlCEox+rBVwypcjLRUP4CH39vPlcGtEfEFz3sTdJchBfpKkAjGvc2bcCFcnn pvhci7ipSkV82C8dLpMDeD11sB5Jhov3U1H07EhW3zQXqNAHNMZCHAG0K7u3PD+1iBzB Ys5ePKXZtyOB4j+LlQDP87tUBUp8sUPah35n/lcLu9oiSDozbdjeZAR7ZUcNklHHZzFg 2QkFhJNNFuFz4fpVBhq4ME7LAr2lmeXTSJ3rQCQsmmk3MJe/9Ar1dE/VJFlK3CfSad6E oBIA== X-Gm-Message-State: AOJu0YyfcXXu4TNRiaUNyUSFoba4d6EGp+YkwwXQwrW1wxaXUEkkhZiK cfuOYG/9a7gMx7vrcU+23GgnKq3jIf903xv5XvA+d9Nw1Q09dUJ5cUdc/YbrDQA= X-Google-Smtp-Source: AGHT+IF89NybvKHB9kLMEhRQ5pL+Bu+Re8XZLakHb9MbDTAQKKnH0KFVBkXxEw77E5t65pn3F9JoPQ== X-Received: by 2002:a05:6a20:9f45:b0:1a0:f616:32be with SMTP id ml5-20020a056a209f4500b001a0f61632bemr11202114pzb.10.1709398929947; Sat, 02 Mar 2024 09:02:09 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id lp3-20020a056a003d4300b006e4c3a6da36sm4700193pfb.202.2024.03.02.09.02.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Mar 2024 09:02:09 -0800 (PST) Date: Sat, 2 Mar 2024 09:02:07 -0800 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org Subject: Re: [PATCH v2 01/71] cocci/rte_memcpy: add script to eliminate fixed size rte_memcpy Message-ID: <20240302090207.428d4853@hermes.local> In-Reply-To: <35267b46-f3cb-4967-a09c-9f512104afca@lysator.liu.se> References: <20240229225936.483472-1-stephen@networkplumber.org> <20240301171707.95242-1-stephen@networkplumber.org> <20240301171707.95242-2-stephen@networkplumber.org> <35267b46-f3cb-4967-a09c-9f512104afca@lysator.liu.se> 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 Sat, 2 Mar 2024 12:19:13 +0100 Mattias R=C3=B6nnblom wrote: > On 2024-03-01 18:14, Stephen Hemminger wrote: > > Rte_memcpy should not be used for the simple case of copying > > a fix size structure because it is slower and will hide problems > > from code analysis tools. Coverity, fortify and other analyzers > > special case memcpy(). > >=20 > > Gcc (and Clang) are smart enough to inline copies which > > will be faster. > > =20 >=20 > Are you suggesting rte_memcpy() calls aren't inlined? With a simple made up example of copying an IPv6 address. rte_memcpy() inlines to: rte_copy_addr: movdqu xmm0, XMMWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 movdqu xmm0, XMMWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 ret Vs memcpy becomes. copy_addr: movdqu xmm0, XMMWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 ret Looks like a bug in rte_memcpy_generic? Why is it not handling 16 bytes correctly. For me, it was more about getting fortify and compiler warnings to catch bugs. For most code, the output should be the same.