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 E957EA0032; Tue, 19 Jul 2022 20:51:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 98972410F1; Tue, 19 Jul 2022 20:51:43 +0200 (CEST) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by mails.dpdk.org (Postfix) with ESMTP id AE48640FAE for <dev@dpdk.org>; Tue, 19 Jul 2022 20:51:42 +0200 (CEST) Received: by mail-vk1-f179.google.com with SMTP id u204so5952682vkb.7 for <dev@dpdk.org>; Tue, 19 Jul 2022 11:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0zCGn5Xh2DnItyBrPTTT5u3vwOBwRaxyRjogmZ93Kuc=; b=TGlpb2Mez/dv+VpllUcWqforZuAKcZE0hkxyCmSQZFxHlJ6GeiyKC+QaIAlntNv70I p8knEJG9R96ELMC9ZmOCB2vla5LInGd6mG4mCLqAlL16g7jrORfUK7bmrutLL6s3L4iQ vq3MBCt5QNsmMMDfbOFEPyy5jffz2GNntItlbPs+xHQ8JcCF51Uy9k+Z4d7kzpNyN6Gp 7TySYGzzww3rwMR2TCFcN0U4uAJTccoUvF/+ijLSxF7bJb/Dw5+FnSUkIGFaFZk7lUL8 DwoeJpBD8s7dVljT2FCmRr5uSMUMgTSua5gFSKyNiBriojtmwbTL+9Xme5Y3VVLmggBl 7qvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0zCGn5Xh2DnItyBrPTTT5u3vwOBwRaxyRjogmZ93Kuc=; b=anLl8Xe4NJ1YClcYJPD+7INbt+0hhdrZQL5Ykb2t2dZ9uQXuV/UbZCLOZTwgRX5qk+ BG0QHX1LJgjMn/YQAtHqpHAHNFy6s79by6vDDnH44CzpjuCoQByodxWKDJNU6h1ZvWUH HHGyPbzismgr/du981K/97AmE9xa5ByHJpTGr54bwtninbZI+nKgwJv1+07/LpH1aP3l RSZ6ypAl33h+EhRu3SV6InBt2PeJXVNKdKMcE5UBQXTM+nIpZWKvBllcgKHGq80uiKgj 6ypHFSA9EtJQC01999/goOItZ/2Ryufqovs3Jxfjbw0MF+I+dXPSDgOlelndZfChIjXg 3kLA== X-Gm-Message-State: AJIora91mfUDMZgNr5gCrT4/Slxtk0mNtoFOt0b0wWfteuUZ+KSpCAFf XRLhZMK4hoW9R1hRPYK9RSRnS16GYs5wolclmgQK6w== X-Google-Smtp-Source: AGRyM1vtDz5WjN7Bp7ZQ4t5jJKLK3C40WAARP0BQ8a57w9LkLYF7uwj+pwe37RfAUgst2MnwPb2jFXk0ATq+Gog2f4I= X-Received: by 2002:ac5:cd22:0:b0:374:d297:4fc0 with SMTP id a2-20020ac5cd22000000b00374d2974fc0mr12104389vkm.37.1658256702074; Tue, 19 Jul 2022 11:51:42 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35D871D4@smartserver.smartshare.dk> <0e4bdf5e-3cac-c8ec-786e-17e0ea16ddf0@linux.vnet.ibm.com> <98CBD80474FA8B44BF855DF32C47DC35D871D5@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D871D5@smartserver.smartshare.dk> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= <kda@semihalf.com> Date: Tue, 19 Jul 2022 20:51:06 +0200 Message-ID: <CALVGJWLSehmiMqvkdQo5jVT6MuXxpkwVWfe_t4LWVaT8OsBq+Q@mail.gmail.com> Subject: Re: [RFC v2] non-temporal memcpy To: =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com> Cc: David Christensen <drc@linux.vnet.ibm.com>, dev <dev@dpdk.org>, Bruce Richardson <bruce.richardson@intel.com>, Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>, Jan Viktorin <viktorin@rehivetech.com>, Ruifeng Wang <ruifeng.wang@arm.com> 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 <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 On Tue, Jul 19, 2022 at 8:41 PM Morten Br=C3=B8rup <mb@smartsharesystems.co= m> wrote: > > > From: David Christensen [mailto:drc@linux.vnet.ibm.com] > > Assume that fallback to the standard temporal memcpy is an acceptable > > implementation when not supported by the architecture, yes? > > Yes, that is exactly what I envisioned. > > Furthermore, stores unaligned to a degree not supported by the architectu= re, will also use temporal mempcy - at least for the unaligned first and la= st part of the copy. The middle (aligned) part may use non-temporal copy. > To clarify, would you envision implementation in the arch-specific headers + generic fallback or a shared one (generic unaligned + call to aligned arch-specific)? First one seems more lean. RISC-V will definitely use generic implementation as non-temporal load/store hints are still not ratified. --=20 Best Regards, Stanis=C5=82aw Kardach