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 D21FAA00C2; Tue, 9 Aug 2022 17:26:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 752ED40143; Tue, 9 Aug 2022 17:26:08 +0200 (CEST) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by mails.dpdk.org (Postfix) with ESMTP id DEE7B400EF for ; Tue, 9 Aug 2022 17:26:06 +0200 (CEST) Received: by mail-pl1-f180.google.com with SMTP id m2so11657219pls.4 for ; Tue, 09 Aug 2022 08:26:06 -0700 (PDT) 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=cw45PrLFCRiq1/NaG4AzyLL75syMqWVw92mcYyE2iQc=; b=CwKiZgWjTxSapKZw0CLkD3WRfipYchIwCzXFtPo+kr7CwoevJjs3lNrNIXj+p10Nct re7xwfmFJKPmSc0iRdXUMDwJimEjgMeuJgVVGNG5jNRkTgMiRPB79ehR8SSe2awe8on1 kRRMRtjgq4CPgWct3zBTo1dN2wc0r/p3/obSxb77P/IdodRcD33839wQhVZC7O3I6zSY +/r/HJqeMunQ5XuUGXXNScBuxtYhNZVD4i6gV4u6IF0IOeYeJ7fWENNyseJDX36NIHco CzzWL5mDxE/fu20ooaWAnbq4oUVs6sPtZdkwZo/rrHLlnEolQLNx7F6zui7X7/BhXAtu WTkg== 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=cw45PrLFCRiq1/NaG4AzyLL75syMqWVw92mcYyE2iQc=; b=gLBtzMh03N7tIs1OgF3Qlwa0jQa99bP7gXsLCQ4GBFea4n6fPqYdMAR/TEDgqt/C5v 3E+1kip8qqFQOezweAVj3V6v7BNYJYTLwQy1Bugx8D7Fbz0zQa8Z9qj/KCYbDGhc1bzv SiLxLjrauUylOb0fmd+D/34xmzA0aJsDEbyvck9ts4zePh4KvYP3sWlf9tUNub5haEDn Jy+ODHhRKnnTsAtdzEsU3Voq7SrzvrzStZoOqjwgRDNqXS/9mmNU96LbM1lgULB+t3AO Zfdl5D23GNQVBiFRU9sefVML1bVEDQVbry7MVc7BwhdZ8gxQBewBl3gESaVUxhoZNCjA mRMw== X-Gm-Message-State: ACgBeo1r+5OjH6hphWn3JfjY7S6RSACndygqQdnlWjtOxB4X7KZfEfhV u161a2P1y3PJeoaDO3wSQ6YDnQ== X-Google-Smtp-Source: AA6agR4+hQW7AIDq+7ufa7ruIeo8YrzQY8oswrT9QnHMVA8hSN/MxHUls5IK1jXl9yWl4obKd9HSvQ== X-Received: by 2002:a17:902:ef46:b0:168:bac3:2fd4 with SMTP id e6-20020a170902ef4600b00168bac32fd4mr23486422plx.132.1660058765844; Tue, 09 Aug 2022 08:26:05 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id n8-20020a654508000000b0041a390f276esm8394202pgq.40.2022.08.09.08.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 08:26:05 -0700 (PDT) Date: Tue, 9 Aug 2022 08:26:02 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , , "Bruce Richardson" , "Konstantin Ananyev" , "Jan Viktorin" , "Ruifeng Wang" , "David Christensen" , "Stanislaw Kardach" Subject: Re: [RFC v2] non-temporal memcpy Message-ID: <20220809082602.1fe5bd89@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87247@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35D871D4@smartserver.smartshare.dk> <9ac934d2-ad05-6ec9-3bb6-63986d68d5d3@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D87247@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Tue, 9 Aug 2022 11:46:19 +0200 Morten Br=C3=B8rup wrote: > >=20 > > I don't think memcpy() functions should have alignment requirements. > > That's not very practical, and violates the principle of least > > surprise. =20 >=20 > I didn't make the CPUs with these alignment requirements. >=20 > However, I will offer optimized performance in a generic NT memcpy() func= tion in the cases where the individual alignment requirements of various CP= Us happen to be met. Rather than making a generic equivalent memcpy function, why not have something which only takes aligned data. And to avoid user confusion change the name to be something not suggestive of memcpy. Maybe rte_non_cache_copy()? Want to avoid the naive user just doing s/memcpy/rte_memcpy_nt/ and expect everything to work.