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 07AA4459B1; Mon, 16 Sep 2024 17:11:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A44FA4025F; Mon, 16 Sep 2024 17:11:44 +0200 (CEST) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 9CB3F40150 for ; Mon, 16 Sep 2024 17:11:43 +0200 (CEST) Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-2d8a4bad409so3133204a91.0 for ; Mon, 16 Sep 2024 08:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1726499503; x=1727104303; 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=U96zaDhSb66MNltpj9g5wJv9Nh140euITBHnlFwsiZA=; b=A6PLBGrzT9hiv5UO3uyguBsK/xfKssN78U3TClrjenDBoLeRGj73VTnBDn5WLV0jzI FogQHMxdB5N46XHMm422Sv49534JBpIWvg/MzsK00aMFCQ+Owe/5xV+u4frzZtKCB5ia CGp5aqAf13BFhnc/Ccf4IP+luB4L9374azy6FtyZ3s2tvU2l1Ti9X1W7/0Y7uEj3niGt 7+W3Mea4/kg0Rs7kPMxL5Q7JSgPQ1wNSYSqIKU1zr5xmaAyfdCOQg4jU6gOtHaEYCusI k5ew6RXHHUm3WOT/RLdLDNK7Ih6Pvrxk5cEjoiyZf9JYZikZsz6ssotsOQ8v3FVV/l5N CaRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726499503; x=1727104303; 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=U96zaDhSb66MNltpj9g5wJv9Nh140euITBHnlFwsiZA=; b=TzZCBH8vBg/kkQMX3z02pSD1D0JgHqB1qs1hNsJp8gjEOUnBZa/skeCqp13squn+0Q K3wuT1R1tgHoL/KJCHQusN8sCnvL+jtVLOfzcfVRB6WKERuk3vecujoTJKdSF9OK9u8E ulvGBkOFcQiLI/QDZJj3moOBz55bFf8VIVObwafo0fJsRVI4TlEa4ZXHrDOaWrcwsc2k WqtrDs6JD5qn7DwTXNR5lKzTeWChTL3w55z7Z+QPMNBquzjT5PVkylr4OJCV25ULr1jI CdIxo2n4iqIuDpCZ2wGlW3+uUjvhIbag/k2aXtk/vG65xz4wGrYXoKSZcrM6UEEVkdUv jN8w== X-Forwarded-Encrypted: i=1; AJvYcCUrdaqyR90FY/WsYQkfmsW3kAmtaVR4VTkvEjKrMqPGEoDc0LkxvYT4h9piv10YuNnsfgw=@dpdk.org X-Gm-Message-State: AOJu0YyVs4R7HUbtWRplDxtHHkAW5BrH6eQ2aAOf2f0ZdWAKi3ESfWsv zZwYgCrWaSRbKmCzQj8saFKFb20nyug0EzjkqONV0A9ZGO5tjogkqi9zb461Itk= X-Google-Smtp-Source: AGHT+IHLf+y8ZtDt/+vnHD1PAmQzzKIlw5trnD6m0GbHWyPz12m1si+uppzDmXL9AbSyj8EAhEwrmA== X-Received: by 2002:a17:90b:4a4a:b0:2d3:d398:3c1e with SMTP id 98e67ed59e1d1-2dba0082fb8mr19272758a91.36.1726499502654; Mon, 16 Sep 2024 08:11:42 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2dbb9d972fcsm7440243a91.57.2024.09.16.08.11.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Sep 2024 08:11:42 -0700 (PDT) Date: Mon, 16 Sep 2024 08:11:40 -0700 From: Stephen Hemminger To: "Brandes, Shai" Cc: Ferruh Yigit , Tyler Retzlaff , "dev@dpdk.org" , "Schmeilin, Evgeny" , "Beider, Ron" , "Bernstein, Amit" , "Atrash, Wajeeh" Subject: Re: [PATCH] net/ena: revert redefining memcpy Message-ID: <20240916081140.58c052ab@hermes.local> In-Reply-To: <7f545f9575b444e5b31be18f033a940e@amazon.com> References: <200~bug-1510-3@http.bugs.dpdk.org> <20240812153417.65225-1-stephen@networkplumber.org> <20240912051243.GC6879@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <16f62350-896e-458c-bbb9-0ef3453883c2@amd.com> <7f545f9575b444e5b31be18f033a940e@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 16 Sep 2024 06:33:26 +0000 "Brandes, Shai" wrote: > > Did you have any chance to check/test this patch? > [Brandes, Shai] We are currently conducting tests and will provide an update shortly. In the meantime, could you advise whether it is recommended to entirely avoid using rte_memcpy in our driver, considering we have direct calls to it? There is a long term goal to remove rte_memcpy(). It exists only as workaround for cases where older compilers do not produce optimium code. When rte_memcpy() is used the checks done by fortify, gcc, coverity etc are less and there is higher probability of bugs going undetected. My current recommendation is to only use rte_memcpy() in the data path and for variable size data items.