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 5A414A04A2;
	Sun, 16 Jan 2022 18:59:42 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 530F54115B;
	Sun, 16 Jan 2022 18:59:41 +0100 (CET)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id 0108E40683;
 Sun, 16 Jan 2022 18:59:38 +0100 (CET)
Content-class: urn:content-classes:message
Subject: RE: [PATCH v3] eal: fix unaligned loads/stores in rte_memcpy_generic
Date: Sun, 16 Jan 2022 18:59:26 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86E08@smartserver.smartshare.dk>
In-Reply-To: <20220116083416.05d7a9db@hermes.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PATCH v3] eal: fix unaligned loads/stores in rte_memcpy_generic
Thread-Index: AdgK9uxF2KQseR7jT8KlkoW7u9pucQACzIgQ
References: <20220115194102.444140-1-lucp.at.work@gmail.com>
 <20220116141304.474374-1-lucp.at.work@gmail.com>
 <CAFeRdtAbLvbfua7csPFZwmWxb_7SqLxm_fdb58bnqrkNJjgC7w@mail.gmail.com>
 <20220116083416.05d7a9db@hermes.local>
X-MimeOLE: Produced By Microsoft Exchange V6.5
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
 "Luc Pelletier" <lucp.at.work@gmail.com>
Cc: <bruce.richardson@intel.com>, <konstantin.ananyev@intel.com>,
 "dev" <dev@dpdk.org>, "Xiaoyun Li" <xiaoyun.li@intel.com>,
 "dpdk stable" <stable@dpdk.org>, "Georg Sauthoff" <mail@gms.tf>
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

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Sunday, 16 January 2022 17.34
>=20
> On Sun, 16 Jan 2022 09:33:19 -0500
> Luc Pelletier <lucp.at.work@gmail.com> wrote:
>=20
> > As a side note, and to follow up on Stephen's indication that this =
is
> > 'performance critical code', I think it might be worthwhile to
> > revisit/revalidate the current implementation of rte_memcpy. There's
> a
> > good thread here that mentions rte_memcpy, and its performance on at
> > least one platform/architecture combination is far from being the
> > best:
> >
> > https://github.com/microsoft/mimalloc/issues/201
> >
> > It seems like enhanced rep movsb could be faster on more recent =
CPUs,
> > but that's currently not being used in the current implementation of
> > rte_memcpy.
> >
> > I understand some of this may not be directly related to this patch,
> > but whoever looks at this patch might want to provide their thoughts
> > on whether updating rte_memcpy would be worthwhile? I suspect =
looking
> > at all current public implementations of memcpy (libc, microsoft,
> > compilers builtin implementations, etc.) might help in making
> > improvements.
>=20
> I would prefer that rte_memcpy did not exist at all.
> Instead the system library should always be used.
>=20
> It is only exists because some architectures have slower code
> in glibc.

I wonder if that is still the case?

Otherwise, DPDK is probably full of obsolete optimizations, which should =
be eliminated like this:

http://inbox.dpdk.org/dev/20210918114930.245387-1-mail@gms.tf/