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 50DFDA0552; Mon, 27 Jun 2022 13:12:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA25F400D7; Mon, 27 Jun 2022 13:12:56 +0200 (CEST) Received: from sender11-of-o51.zoho.eu (sender11-of-o51.zoho.eu [31.186.226.237]) by mails.dpdk.org (Postfix) with ESMTP id 5BDAA400D5 for ; Mon, 27 Jun 2022 13:12:55 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1656328360; cv=none; d=zohomail.eu; s=zohoarc; b=Q0OAvT35VoZPvYSZ+wJEcv4qr+Kp1PswJA+QW+cg+uw2X3eXF0ZZPKZDVqrKc1JTaF0nZg3oCUDPTAfQzy6AYRqzmn8B03H8EKYWdevjFZ+B17ET9ZzBZt4vwASQvfvhNNqMmVlPlOQTaTRZAvlaFdTuGBh0JmDUl3JuG+o654o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1656328360; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=w5Fh8jOzKOB7CfVjn7+yXzrcRxKPAIePrFPNo8MFxBQ=; b=lAgzjU3CbB1aPmEcC1CHEF/1TOjnYGhEwYvn7AtA1R+a3LXsNIZqoXZWGj0ReMTdu14Z1694FFqVFfB+3GkcmJk93I6fRUITi9wZOqScDIEnYYzWCJmU47asPu72LaaDmQOCWbLabRpcyOKaGPor9iaBFsUptmlQTIeLsMzITOQ= ARC-Authentication-Results: i=1; mx.zohomail.eu; spf=pass smtp.mailfrom=liangma@liangbit.com; dmarc=pass header.from= Received: from C02GF04TMD6V (ec2-35-176-106-177.eu-west-2.compute.amazonaws.com [35.176.106.177]) by mx.zoho.eu with SMTPS id 1656328358152181.51771795891614; Mon, 27 Jun 2022 13:12:38 +0200 (CEST) Date: Mon, 27 Jun 2022 12:12:36 +0100 From: Liang Ma To: Konstantin Ananyev Cc: Stephen Hemminger , Huichao Cai , dev@dpdk.org, konstantin.ananyev@intel.com, David Marchand Message-ID: Subject: Re: [PATCH] ip_frag: replace the rte memcpy with memcpy References: <1655561380-64616-1-git-send-email-chcchc88@163.com> <20220622193520.16e7c2e5@hermes.local> <3ae8f3d7-5578-d841-9458-24d6f203da0d@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3ae8f3d7-5578-d841-9458-24d6f203da0d@yandex.ru> X-ZohoMailClient: External 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 Fri, Jun 24, 2022 at 06:25:10PM +0100, Konstantin Ananyev wrote: > 23/06/2022 03:35, Stephen Hemminger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Wed, 22 Jun 2022 23:49:39 +0100 > > Konstantin Ananyev wrote: > >=20 > > > > @@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte= _ipv4_hdr *dst, > > > > =09=09const struct rte_ipv4_hdr *src, uint16_t header_len, > > > > =09=09uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf) > > > > { > > > > -=09rte_memcpy(dst, src, header_len); > > > > +=09memcpy(dst, src, header_len); > > >=20 > > >=20 > > > 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? > >=20 > > Do you have any performance tests. The ip header options are very small= . >=20 >=20 > 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 >=20 > Konstantin >=20 >=20 For some small(<1k) size, " rep movsb" is very fast. much faster than I expected. I just noticed this in another application.=20