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 140C1A04A2; Sun, 16 Jan 2022 17:34:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EDBC4115D; Sun, 16 Jan 2022 17:34:21 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id E7197410E8 for ; Sun, 16 Jan 2022 17:34:19 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id l16so8374403pjl.4 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=Bz9ZV98K7tLh+8e4OSoNUdRYjffz0V7L3nwr63xc/xQaSzIl6JlLXv8JP4pWYhvhIW 6r9kjlDwcgjLW3KKQzuhX3tiqASaQUPzPTWTewaoOaZl9KWTCsOHtjS6RwoRplVv77WT 8Z7KooD96byfTDytu/yZnXuE86TKRXskUXLwkYHv8OoU8lyYKSmdSoubuxI+s2el/NlC spHaO4NKhr+9sWkRN5iBJfFo8zgimhtmAC5ihxwnOJJuKEjDoyfZXMusGHanev6LuANQ SMo7F6CvRsI1OsOF3Zlugt/3vNnUXRmC7cnS90VHXNAqfK22tcFa3OnTicNNKA5AYaNv Zl5Q== X-Gm-Message-State: AOAM532xGggcBEJW81Xz+nvtoJJUF55nzMPhMONOZCdr6UnlCpu5Kibu Yim+cNqFPPZ4zj3V2W5CrfOToQ== 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: 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 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.