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 9176DA0544; Wed, 8 Jun 2022 22:52:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 830764069C; Wed, 8 Jun 2022 22:52:08 +0200 (CEST) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by mails.dpdk.org (Postfix) with ESMTP id 4393840689 for <dev@dpdk.org>; Wed, 8 Jun 2022 22:52:07 +0200 (CEST) Received: by mail-pg1-f177.google.com with SMTP id f65so9815921pgc.7 for <dev@dpdk.org>; Wed, 08 Jun 2022 13:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=iA4V8Un+ES4u2PAB+02VqW11OmatHcv/VO8W1H+5syE=; b=0H7sUypl9zxKInb4b0QZHZmzdAkRC9v+U6K8Pj19VOIjgSdJVw8xSHeKks6e/MtlNu B07jKUMF50QgQPDR5lZQJ87SoSeaJ+oiZKirWvJfIHImEzLEO9QBZo2CV+TWS8GegjNc a3js4HovRrPoFQ0JW+AWh1PGKaQMCJ1e4vrEFxoInupmdPlsmTm3HvoqqNEhcLoEKmK4 BIyKyMv8DFIQXQrLWFunLRoAes/1hx8PsynXHf8DBGJBDfPuZdxCjlBUItR+2Nr2UMNQ W0ZztfpayTSkhE/gWwWpfRVR35AV8s76GgZPB0ubARR0h09HW9ddvi2A2nbF0FzjR99T E2wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iA4V8Un+ES4u2PAB+02VqW11OmatHcv/VO8W1H+5syE=; b=0uBKezmmBVk1rmiRWfCyFvu3VMTYa6V6xWH57NiGU4jNVQodAq+noQToZofRCxOYQl Vkdr7a2JLOrbhsduP+alvrfKVNvIoNOLN3Y76z7EFN73ZpsWXLi8RfdaXwtXnczspaYd /Geh9vdTPIidVRs4/XQmSyxljHoq1aTNEK76b3OnZeg6LK43yQUt/QGPKAO1DzhoaJNS KSnz+i4MWWh2gHIhczxXHFazVZ5ag3b6/ouAZVWs3KwAd+DIZGGfrCRSqqQ/wVjVtTj0 Kj4dTvGufjTp1hov7nRI2T1HJ825yvlCMxHXtCVj0RKX2drocgpoTeOvhOSLCr41BSfJ vdrg== X-Gm-Message-State: AOAM5312q2+x2YKsJOFGeJ+iYiTrKChecwp8c41m4OOVzSCFIs9Pi4sZ BI9Uw7rd6+Bj9+9qnBK9M6Sw9w== X-Google-Smtp-Source: ABdhPJz98fEE/45USPliYoHvZAdJt7JoQvnoHFM8lBei7iiuoRlmoqifAoVKFFK1rX0ee1yBX5ze3Q== X-Received: by 2002:a05:6a00:a8f:b0:51b:5ca1:47f1 with SMTP id b15-20020a056a000a8f00b0051b5ca147f1mr36340407pfl.50.1654721526352; Wed, 08 Jun 2022 13:52:06 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id f132-20020a636a8a000000b003fd31d64e23sm11191024pgc.63.2022.06.08.13.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 13:52:05 -0700 (PDT) Date: Wed, 8 Jun 2022 13:52:03 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: =?UTF-8?B?TWljaGHFgg==?= Krawczyk <mk@semihalf.com> Cc: dev <dev@dpdk.org>, Marcin Wojtas <mw@semihalf.com>, Shai Brandes <shaibran@amazon.com>, Evgeny Schemeilin <evgenys@amazon.com>, Igor Chauskin <igorch@amazon.com> Subject: Re: [RFC 1/8] net/ena: fix warnings related to rte_memcpy and gcc-12 Message-ID: <20220608135203.5711e412@hermes.local> In-Reply-To: <CAJMMOfMMqYPLPMJr71pzo1OUAejroHQhaYDt=QFybMw_gDBFsA@mail.gmail.com> References: <20220607171746.461772-1-stephen@networkplumber.org> <20220607171746.461772-2-stephen@networkplumber.org> <CAJMMOfOt7G+2mgODr8u8vdU2RtUH=bUzPHLT8uuuXRaA0-sTbg@mail.gmail.com> <20220608083231.1bcb1a01@hermes.local> <CAJMMOfMMqYPLPMJr71pzo1OUAejroHQhaYDt=QFybMw_gDBFsA@mail.gmail.com> 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 <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 Wed, 8 Jun 2022 21:18:15 +0200 Micha=C5=82 Krawczyk <mk@semihalf.com> wrote: > =C5=9Br., 8 cze 2022 o 17:32 Stephen Hemminger <stephen@networkplumber.or= g> > napisa=C5=82(a): > > > > On Wed, 8 Jun 2022 14:29:58 +0200 > > Micha=C5=82 Krawczyk <mk@semihalf.com> wrote: > > =20 > > > wt., 7 cze 2022 o 19:17 Stephen Hemminger <stephen@networkplumber.org> > > > napisa=C5=82(a): =20 > > > > > > > > Rte_memcpy is not needed for small objects only used on control > > > > path. Regular memcpy is as fast or faster and there is more > > > > robust since static analysis etc knows what it does. > > > > > > > > In this driver it was redefining all memcpy as rte_memcpy > > > > which is even worse. =20 > > > > > > Hi Stephen, > > > > > > I would like to shed some light on why we're redefining all the memcpy > > > as rte_memcpy. The ENA HAL is unmodifiable, as it's shared across many > > > platforms and we cannot simply adjust it for the DPDK. We can use the > > > ena_plat_dpdk.h to change the ena_com (HAL) definitions, and that's > > > what we're doing with memcpy. It's being used on the data path for the > > > Tx, to copy the bounce buffers. Following the recommendations in [1] > > > plus the results from [2], we wanted to make use of the optimized > > > memcpy on the ENA's data path as well to reduce the CPU time spent in > > > the PMD. I'm worried that removing rte_memcpy from the ena_plat_dpdk.h > > > will result in some performance degradation for the ENA data path. > > > However I understand your concerns for the control path and I'm ok > > > with it. > > > > > > [1] https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.htm= l#memory > > > [2] https://www.intel.com/content/www/us/en/developer/articles/techni= cal/performance-optimization-of-memcpy-in-dpdk.html > > > > > > Thanks, > > > Michal > > > =20 > > > > > > I admit to having little sympathy unfixable for base/ style code. > > You could have just replaced memcpy() in their with an abstraction layer > > like other drivers. > > =20 >=20 > We'll probably end up with the solution you're suggesting. For now > let's remove the memcpy redefinition at all to suppress the warnings. >=20 > Acked-by: Michal Krawczyk <mk@semiahalf.com> Lets see if we can fix rte_memcpy() on x86 first. It seems to me that rte_memcpy() should be an inline that only handles vari= able size data, and use __builtin_memcpy() automatically for fixed size values.