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 1120AA0093; Fri, 24 Jun 2022 19:26:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B75364069D; Fri, 24 Jun 2022 19:26:23 +0200 (CEST) Received: from forward501p.mail.yandex.net (forward501p.mail.yandex.net [77.88.28.111]) by mails.dpdk.org (Postfix) with ESMTP id 1E41D400EF for ; Fri, 24 Jun 2022 19:26:22 +0200 (CEST) Received: from sas1-43b74f7725b7.qloud-c.yandex.net (sas1-43b74f7725b7.qloud-c.yandex.net [IPv6:2a02:6b8:c14:391a:0:640:43b7:4f77]) by forward501p.mail.yandex.net (Yandex) with ESMTP id 5367462145B7; Fri, 24 Jun 2022 20:25:14 +0300 (MSK) Received: from sas2-ffeb92823cb1.qloud-c.yandex.net (sas2-ffeb92823cb1.qloud-c.yandex.net [2a02:6b8:c08:6803:0:640:ffeb:9282]) by sas1-43b74f7725b7.qloud-c.yandex.net (mxback/Yandex) with ESMTP id SxIdYvnG38-PDhaIKvi; Fri, 24 Jun 2022 20:25:14 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1656091514; bh=vid5ttdUXo9zwHkJWCDCc2l87Cr7ifEpMucP9EygMkY=; h=In-Reply-To:From:Subject:Cc:References:Date:Message-ID:To; b=YA5YWob/dISE4Kl85bkstoF+VWOIgPc7ejRsKuopQm407asrJ2G85pze7y5FB1Qzh RqkP65q7ISvv43nzFk0ZyxnX9KiL1iODUCMrwwWCKZgwgfZ2vrYeZbRf4aJvea8EbV r5bJntYRdQbBaGLgfhvHNxWNs7U3XOUeVbGWx7pA= Authentication-Results: sas1-43b74f7725b7.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas2-ffeb92823cb1.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id SXy2FlzvT3-PCMuNTQw; Fri, 24 Jun 2022 20:25:13 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <3ae8f3d7-5578-d841-9458-24d6f203da0d@yandex.ru> Date: Fri, 24 Jun 2022 18:25:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] ip_frag: replace the rte memcpy with memcpy Content-Language: en-US To: Stephen Hemminger Cc: Huichao Cai , dev@dpdk.org, konstantin.ananyev@intel.com, David Marchand References: <1655561380-64616-1-git-send-email-chcchc88@163.com> <20220622193520.16e7c2e5@hermes.local> From: Konstantin Ananyev In-Reply-To: <20220622193520.16e7c2e5@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 23/06/2022 03:35, Stephen Hemminger пишет: > On Wed, 22 Jun 2022 23:49:39 +0100 > Konstantin Ananyev wrote: > >>> @@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst, >>> const struct rte_ipv4_hdr *src, uint16_t header_len, >>> uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf) >>> { >>> - rte_memcpy(dst, src, header_len); >>> + memcpy(dst, src, header_len); >> >> >> I am fine with replacements in test and inside the lib, for cases >> where 'len' parameter is constant value. >> Though as I said before, here 'header_len' is not a constant value. >> Are you sure it will not introduce any performance regression? > > Do you have any performance tests. The ip header options are very small. From my experience - usually it is not about how big or small amount we need to copy. It is about can compiler evaluate 'size' parameter for memcpy() at compilation time or not. If it can, great - it will most likely replace memcpy() with some really well optimized code. If not it has to generate a proper call to actual memcpy() function. Which again, can be well optimized, but the overhead of the function call itself can still be noticeable, specially for small copies. Anyway, as I can see, David already integrated these changes anyway. So now, we'll have to wait and see would anyone complain or not. About performance testing, the only one I am aware about: examples/ip_fragmentation Konstantin