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 5F773A04FD; Wed, 8 Jun 2022 21:18:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 005FC40689; Wed, 8 Jun 2022 21:18:28 +0200 (CEST) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by mails.dpdk.org (Postfix) with ESMTP id CD5C740042 for ; Wed, 8 Jun 2022 21:18:27 +0200 (CEST) Received: by mail-qk1-f179.google.com with SMTP id c144so13738260qkg.11 for ; Wed, 08 Jun 2022 12:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FEb8x9OQj2bbv4r1gQ8Y9+KSQ7XInr1wSoYTD0OJu7w=; b=HaA0e2qNtLe0GxU3e/NlMsHR8xor7ROXle8vy7D7D3U2pPLryT7ol+fzX6Gaa7Khfb o3y2l5rZlpnsYx0S5QQvqHxpnjdheynHj0ChP8ysv5FaTI/biD+MZU0bCFL6u762pLh/ 7oYUr05CYNG0UR+1UJwaXWWAqyulM39ETBh1/06UZ56OcYwL0En3G335bh967gVVpkbm r79tEQdKTHW5ZyPz2obJdMp/6myW1SfsiEHWswBCwmwnQ/BSaLmYtNL4nQg+XCdKiFE5 016D6mhutFdyZ5WQ1g85AA7oDjURRA+IK7Hl7ro7v4lxvwXn/0EDdWqFhhxPHErZBU8s /oSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FEb8x9OQj2bbv4r1gQ8Y9+KSQ7XInr1wSoYTD0OJu7w=; b=0PQon2jlybMCDEA42W7ggclikdcxLKQqKL8gn2jbpJDLB4bjthcjyn34OqWG7slxV+ dE31aVatPrtqSWCr/uLdYTA8RkIhmNreQwVURXPYfffVDD61eL293xv6u8IJn7AA1yqI 5DzIEpm5TCpPHxg+Dt747TLRI7zQuBGlSNd9Bn/smBgIoPBfaqoIn559ED+FkuiTRFU8 NmywmVGXmwRmBybsRu16RpFZyt0VPRzGDaJquPC56wc7nT9HoZIEyqwyLfdhzOY0emp3 9E6vhO0R3FQshKBOMRxrW2stOg44ARuK92ql8kWYPPjVVuLF+kmYfZcya6/oE+jUVWFi yaGw== X-Gm-Message-State: AOAM532CfUZi0V2gESzUrRo9VEAYYqMPo9+dY0O5/IRHS9vxKZ3Dr8FW hii4c+hoeXGrz3yoFg1n7m2vHJIalqT/5WQZ80WcuQ== X-Google-Smtp-Source: ABdhPJxzZf0BaQauyRIY4cXBx3buNRnpK3hJ/fJRoyDi23yJYIKh0trLkWyEDDCVepb1/F5UwXNqAsBDd+5Lfvo4ZVM= X-Received: by 2002:a05:620a:1b94:b0:6a6:d20c:c2fd with SMTP id dv20-20020a05620a1b9400b006a6d20cc2fdmr9097567qkb.459.1654715906986; Wed, 08 Jun 2022 12:18:26 -0700 (PDT) MIME-Version: 1.0 References: <20220607171746.461772-1-stephen@networkplumber.org> <20220607171746.461772-2-stephen@networkplumber.org> <20220608083231.1bcb1a01@hermes.local> In-Reply-To: <20220608083231.1bcb1a01@hermes.local> From: =?UTF-8?Q?Micha=C5=82_Krawczyk?= Date: Wed, 8 Jun 2022 21:18:15 +0200 Message-ID: Subject: Re: [RFC 1/8] net/ena: fix warnings related to rte_memcpy and gcc-12 To: Stephen Hemminger Cc: dev , Marcin Wojtas , Shai Brandes , Evgeny Schemeilin , Igor Chauskin 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 =C5=9Br., 8 cze 2022 o 17:32 Stephen Hemminger napisa=C5=82(a): > > On Wed, 8 Jun 2022 14:29:58 +0200 > Micha=C5=82 Krawczyk wrote: > > > wt., 7 cze 2022 o 19:17 Stephen Hemminger > > napisa=C5=82(a): > > > > > > 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. > > > > 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.html#= memory > > [2] https://www.intel.com/content/www/us/en/developer/articles/technica= l/performance-optimization-of-memcpy-in-dpdk.html > > > > Thanks, > > Michal > > > > > 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. > 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. Acked-by: Michal Krawczyk