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 7B7AAA04A2 for ; Sun, 16 Jan 2022 17:34:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 58B5F40683; Sun, 16 Jan 2022 17:34:21 +0100 (CET) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id C34FC40683 for ; Sun, 16 Jan 2022 17:34:19 +0100 (CET) Received: by mail-pl1-f177.google.com with SMTP id e8so4261557plh.8 for ; Sun, 16 Jan 2022 08:34:19 -0800 (PST) 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=YE9fPZr23jlOdBG+rwF0E1Fz2NM21HX1li7fg0+MuBE=; b=5/N2wTulMs+H9tUzvJE/Hmjpnfmkre4cvtv+VF1sQ9OnRxwZPkY4d9eicgW/p23MBL DJCCA1yzSDeY1WCiFVaW8AeQjGFVT1sN5w5DHdzz2FqMwPk6TRybUVKJRZ/HKoAuKIXM W8QuuvwS8+FBWXnqeEIgBQ5S6kjDhCBqUcj7ChMK6CRjTvBsTgeSEpIAnKaZ4ntSK+3I jzHuUwkqjxsf1n60+pqu7UrtNu1/go/7+7iGkMCXbkkY4NgUM9ZKiOxzdU0FqvxwHFA1 5nIx/ei+jC41rkeK+mLR0YpbfUruJKJwdddJ4OK6TPpcsaayres0FueusS2AGsW2r6/u z20w== 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=YE9fPZr23jlOdBG+rwF0E1Fz2NM21HX1li7fg0+MuBE=; b=XqB8ruJFJnRxXaqPpiK2zui6UjFnY8o12F4Wo5ZXHSAauBRr3KSf2rknbVSq9eVm/S VaeUh4aKoppzww/I2dD4mjv03DNfzauOgNBFtoQkONnx3fj4nKpQR7fcX8cC8pVUSRFO K9UTHx2q2XOc8KD5/MV8zjVl723fFeP3+y7eny4NdOXygUrTq7cSqrU9tGjJFnWnE8Ls 5F+9SuQlBvbdGdTPk0fxlrln8Pbr7ANxrjoyPoqT4+JNZbmnBH5Y/jpQqKign/3YXVTi QysadYfomeqkyl+62El11cYAA/OX8LoBLAp2Q3GV+wROniFNaOhgmayj9gcASEpTpVlw L6og== X-Gm-Message-State: AOAM532Go56H7S8gO1X6HtFvj2IFTxCftJHpPao7uc2VpKM+V6nx6nwM 89SKeuFtqzN65NPL/Ua6LU/kf6zSQn0kzA== X-Google-Smtp-Source: ABdhPJyAFsbkRrUDt70KfeP0ZekmYhxtFA9Zj4YgR6i8CM/4zKH13Gl2tAZTUmoN5gGJtCH2/I0eXg== X-Received: by 2002:a17:902:7485:b0:14a:26a7:81e9 with SMTP id h5-20020a170902748500b0014a26a781e9mr18828488pll.88.1642350859021; Sun, 16 Jan 2022 08:34:19 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id s8sm11694609pfk.165.2022.01.16.08.34.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jan 2022 08:34:18 -0800 (PST) Date: Sun, 16 Jan 2022 08:34:16 -0800 From: Stephen Hemminger To: Luc Pelletier Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com, dev , Xiaoyun Li , dpdk stable Subject: Re: [PATCH v3] eal: fix unaligned loads/stores in rte_memcpy_generic Message-ID: <20220116083416.05d7a9db@hermes.local> In-Reply-To: References: <20220115194102.444140-1-lucp.at.work@gmail.com> <20220116141304.474374-1-lucp.at.work@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Sun, 16 Jan 2022 09:33:19 -0500 Luc Pelletier wrote: > 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. I would prefer that rte_memcpy did not exist at all. Instead the system library should always be used. It is only exists because some architectures have slower code in glibc.