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 B30E2A00C2; Tue, 9 Aug 2022 13:53:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5F1964069C; Tue, 9 Aug 2022 13:53:29 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id E19F140143 for ; Tue, 9 Aug 2022 13:53:27 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3519E75A7 for ; Tue, 9 Aug 2022 13:53:27 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 33BED75A6; Tue, 9 Aug 2022 13:53:27 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.7 Received: from [192.168.1.59] (unknown [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 6FD4373E6; Tue, 9 Aug 2022 13:53:25 +0200 (CEST) Message-ID: Date: Tue, 9 Aug 2022 13:53:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC v2] non-temporal memcpy Content-Language: en-US To: =?UTF-8?Q?Morten_Br=c3=b8rup?= Cc: dev@dpdk.org, Stephen Hemminger , Konstantin Ananyev , Bruce Richardson , Honnappa Nagarahalli References: <98CBD80474FA8B44BF855DF32C47DC35D871D4@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D871DB@smartserver.smartshare.dk> <262c214b-7870-a221-2621-6684dce42823@yandex.ru> <98CBD80474FA8B44BF855DF32C47DC35D871E6@smartserver.smartshare.dk> <2c646d01-14d0-e5cb-2d7c-50c8456fc3e5@yandex.ru> <98CBD80474FA8B44BF855DF32C47DC35D8720C@smartserver.smartshare.dk> <5e1567fb744841a0915348397a81b99d@huawei.com> <20220729090548.2cdffd4e@hermes.local> <4ef33229-c9dd-3043-7f2d-25102b823cac@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D87245@smartserver.smartshare.dk> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87245@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2022-08-09 11:24, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] >> Sent: Sunday, 7 August 2022 22.41 >> >> On 2022-07-29 18:05, Stephen Hemminger wrote: >>> >>> It makes sense in a few select places to use non-temporal copy. >>> But it would add unnecessary complexity to DPDK if every function in >> DPDK that could >>> cause a copy had a non-temporal variant. >> >> A NT load and NT store variant, plus a NT load+store variant. :) > > I considered this, but it adds complexity, and our use case only needs the NT load+store. So I decided to only provide that variant. > > I can prepare the API for all four combinations. The extended function would be renamed from rte_memcpy_nt_ex() to just rte_memcpy_ex(). And the rte_memcpy_nt() would be omitted, rather than just perform rte_memcpy_ex(dst,src,len,F_DST_NT|F_SRC_NT). > > What does the community prefer in this regard? > I would suggest just having a single function, with a flags or an enum to signify, if load, store or both should be non-temporal. If all platforms honor all combinations is a different matter. Is there something that suggests that this particular use case will be more common than others? When I've used non-temporal memcpy(), only the store side was NT, since the application would go on an use the source data. >> >>> >>> Maybe just having rte_memcpy have a threshold (config value?) that if >> copy is larger than >>> a certain size, then it would automatically be non-temporal. Small >> copies wouldn't matter, >>> the optimization is more about not stopping cache size issues with >> large streams of data. >> >> I don't think there's any way for rte_memcpy() to know if the >> application plan to use the source, the destination, both, or neither >> of >> the buffers in the immediate future. > > Agree. Which is why explicit NT function variants should be offered. > >> For huge copies (MBs or more) the >> size heuristic makes sense, but for medium sized copies (say a packet >> worth of data), I'm not so sure. > > This is the behavior of glibc memcpy(). > Yes, but, from what I can tell, glibc issues a sfence at the end of the copy. Have a non-temporal memcpy() with a different memory model than the compiler intrinsic memcpy(), the glibc memcpy() and the DPDK rte_memcpy() implementations seems like asking for trouble. >> >> What is unclear to me is if there is a benefit (or drawback) of using >> the imaginary rte_memcpy_nt(), compared to doing rte_memcpy() + >> clflushopt or cldemote, in the typical use case (if there is such). >> > > Our use case is packet capture (copying) to memory, where the copies will be read much later, so there is no need to pollute the cache with the copies. > If you flush/demote the cache line you've used more or less immediately, there won't be much pollution. Especially if you include the clflushopt/cldemote into the copying routine, as opposed to a large flush at the end. I haven't tried this in practice, but it seems to me it's an option worth exploring. It could be a way to implement a portable NT memcpy(), if nothing else. > Our application also doesn't look deep inside the original packets after copying them, there is also no need to pollute the cache with the originals. > See above. > And even though the application looked partially into the packets before copying them (and thus they are partially in cache) using NT load (instead of normal load) has no additional cost. >