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 48E4DA0544; Mon, 10 Oct 2022 13:58:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E6C524021E; Mon, 10 Oct 2022 13:58:51 +0200 (CEST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by mails.dpdk.org (Postfix) with ESMTP id BD23640146 for ; Mon, 10 Oct 2022 13:58:50 +0200 (CEST) Received: by mail-lj1-f179.google.com with SMTP id c20so498714ljj.7 for ; Mon, 10 Oct 2022 04:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=xh/WnVrQ0i6qiGXAPHd44vF2jlXzmKA5Wo8vRt19qqo=; b=XzfkZX8/fKqsmd59RUFEFy69E9yQy8wpFRfQ92tFxgTxbHeScLkbiqNt2Ka2oRlm2F R8nzK4iK2kOc3EMyqgD4yih2j5ER5B8T6KjAXFCFHaa45sFtFYQfjK7W5vXXwR+l/iYV mAQun2oeyjKgGkxLWZWFSDOI6TnEVzJYT2ZykZsOF/PYS4m4jPe+36olAYwv+lVdoc3v dIX/dQlC8quJAfb8ECfgQaKWLJLlbMaQBqrVU2XdcUypd3e9z7bptgu3AWCLFYc2tJPw JJeEjlsu4KUsAK6VCBpiKm00QvnWQ73HvTVei0SRxoKepb09Y8LeSEYhOsKTCNgWK8H/ 8/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xh/WnVrQ0i6qiGXAPHd44vF2jlXzmKA5Wo8vRt19qqo=; b=G3LYSTttFx4K/1+bI7eAAF2YflmN58mVwV3UaCFURWhkpDKBfelI3DowsVOQtMnRM/ UJE3JuIAV32b93/CWw/0tcbaIIMBBDghG7NNcgiCANWgRaev6/gBkPCa6tbgeoKV40Hg BCfSOPFiO5VAmjBRCDX7tQghlmxmIeckyzRwn+IU/iC5hQVnNUHgmJvpK0dHFRbCV8hI bvKbxhhItrZHgd1hWIwAI5nPGvd9TsSqxHZsllLB3aMvYsxanqQI8hMgO+XOOOYQwu1D OHkZgsEr9htF1m7bObI9C6OP4491Yya6Px5rQwu03Uopelx0HEw94LJllFbK2q2TxLaG dq0A== X-Gm-Message-State: ACrzQf11RRXvfRJStMzp8Tl+pwQMsEqzfP+0aoKpk7t8XEb9PsrQU2Ha DegqCOKP6/3ycWjZqmqsIOI55A== X-Google-Smtp-Source: AMsMyM5wl8HiGEIpKQ4S580vJsx+FqiKK5ecSeqY+lsBU6nH21VVDaTnMoNic+eyOSupzne+x6UsVg== X-Received: by 2002:a2e:9198:0:b0:26e:5551:3ecb with SMTP id f24-20020a2e9198000000b0026e55513ecbmr6066912ljg.279.1665403128789; Mon, 10 Oct 2022 04:58:48 -0700 (PDT) Received: from toster ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id h28-20020a19ca5c000000b00498fe38ea0fsm1393381lfj.174.2022.10.10.04.58.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 04:58:48 -0700 (PDT) Date: Mon, 10 Oct 2022 13:58:43 +0200 From: Stanislaw Kardach To: Morten =?utf-8?Q?Br=C3=B8rup?= Cc: Mattias =?utf-8?B?UsO2bm5ibG9t?= , konstantin.v.ananyev@yandex.ru, Honnappa.Nagarahalli@arm.com, stephen@networkplumber.org, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com, drc@linux.vnet.ibm.com, dev@dpdk.org Subject: Re: [PATCH] eal: non-temporal memcpy Message-ID: <20221010115843.z6xrrhk6snljpb6i@toster> References: <98CBD80474FA8B44BF855DF32C47DC35D8728A@smartserver.smartshare.dk> <20221006203426.78743-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35D873BC@smartserver.smartshare.dk> <730193b1-9574-ff59-28be-c1449cba0ffc@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D873C3@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D873C3@smartserver.smartshare.dk> 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 Mon, Oct 10, 2022 at 11:36:11AM +0200, Morten Brørup wrote: > > For large copies, which I'm guessing is what non-temporal stores are > > usually used for, this is hair splitting. For DPDK applications, it > > might well be at least somewhat relevant, because such an application > > may make an enormous amount of copies, each roughly the size of a > > packet. > > > > If we had a rte_memcpy_ex() that only cared about copying whole cache > > line in a NT manner, the application could add a clflushopt (or the > > equivalent) after the copy, flushing the the beginning and end cache > > line of the destination buffer. > > That is a good idea. > > Furthermore, POWER and RISC-V don't have NT store, but if they have a cache line flush instruction, NT destination memcpy could be implemented for those architectures too - i.e. storing cache line sized blocks and flushing the cache, and letting the application flush the cache lines at the ends, if useful for the application. On RISC-V all stores are from a register (scalar or vector) to a memory location. So is the reasoning behind flushing the cache line to free it up to other data? Other than that there is a ratified RISC-V extension for cache management operations (including flush) - Zicbom. NT load/store hints are being worked on right now. -- Best Regards, Stanislaw Kardach