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 4D12EA00C4; Fri, 29 Jul 2022 18:05:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 385E74069C; Fri, 29 Jul 2022 18:05:53 +0200 (CEST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mails.dpdk.org (Postfix) with ESMTP id AC99840151 for ; Fri, 29 Jul 2022 18:05:51 +0200 (CEST) Received: by mail-pl1-f181.google.com with SMTP id y15so4982604plp.10 for ; Fri, 29 Jul 2022 09:05:51 -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=KpDWJtirPdlCZA+zDWQF708//SK1P8xRBTWSykjVr5Y=; b=ggvR/mGs6cLX++08tAf78mzLGHuS8y4j7OiG0lqF/DXBaDY5e9FwJ7s/mtxwsgxZJu V1EOZiDplqyOiZ3uOoaK0aSycdHNEPWHHI6/j8Ol3VOe0VAUg1iSFnqpodi6DLUd/HzK zDWv8DnQSx8f/zZOX+FBB+QuaUoIlLs76YB5dh26AK0rEC9HADMB+HN+usXbOM0N4c1n hFm4khUCRaoI7UDrp55xrGlxZPnNutDX/pUga5ICRg5dSZJcEU5JPHwy/GPwD0OsdjlL usHWsvyqES35ttussTbiGT1R7ALRIqITZamRwpXr2YsAnZKY9L8NlXwjriZoT5Ile5a5 vkGg== 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=KpDWJtirPdlCZA+zDWQF708//SK1P8xRBTWSykjVr5Y=; b=k/zz1vR+l53ZcZY6n2//GG47i9ZsZutGD7qv2tC7XMsGA2W0QSYwfqK8TvXjv4hJpf LgIRAs/6BiB8pgAQRKO/mZUsJ7hOFzV7lZYy7nEQAMfza/RH87s10lyD+brsKidD3Atl uR9QobGjNxrI3IuIZsLzE4+ZyYUeX8J/avIyHUYB2Ey2xen+3GVHQ+4XKc3ymxrID0eD 6AbR24+eL8u7xNPvEEtErdkTIG4hbRm+jTSghuP6p1cVtZGGLWo43M8VcW4vLMmeSBNR ccQ6TiBNjFjAioBea4ohm5KocvHKFBGkyJvrY5dwoY/LbXOhcBCiAHac3bnaRCxQpXsU jBOA== X-Gm-Message-State: ACgBeo2NcNges4Au3KIH+ZHjCinQin7yLmbi79Eu0cPz/AvKg6U4RJp+ 0J98rJmn8Si6J8bVCCD7gdrMBg== X-Google-Smtp-Source: AA6agR7H9eOV9zTjrapiN7EXohDlT9u0tL18p/s1zTbH7ishM6Xx6UrEHRWDfFAJgTFqTYrDeI9C+g== X-Received: by 2002:a17:902:bd08:b0:16d:4230:cb45 with SMTP id p8-20020a170902bd0800b0016d4230cb45mr4518375pls.59.1659110750824; Fri, 29 Jul 2022 09:05:50 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id z25-20020aa79f99000000b005292729cc5csm3054575pfr.160.2022.07.29.09.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Jul 2022 09:05:50 -0700 (PDT) Date: Fri, 29 Jul 2022 09:05:48 -0700 From: Stephen Hemminger To: Konstantin Ananyev Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , "Konstantin Ananyev" , "dev@dpdk.org" , Bruce Richardson , Jan Viktorin , Ruifeng Wang , David Christensen , "Stanislaw Kardach" Subject: Re: [RFC v2] non-temporal memcpy Message-ID: <20220729090548.2cdffd4e@hermes.local> In-Reply-To: <5e1567fb744841a0915348397a81b99d@huawei.com> 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> 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 Fri, 29 Jul 2022 12:13:52 +0000 Konstantin Ananyev wrote: > Sorry, missed that part. > > > > > > Another question - who will do 'sfence' after the copying? > > > Would it be inside memcpy_nt (seems quite costly), or would > > > it be another API function for that: memcpy_nt_flush() or so? > > > > Outside. Only the developer knows when it is required, so it wouldn't make any sense to add the cost inside memcpy_nt(). > > > > I don't think we should add a flush function; it would just be another name for an already existing function. Referring to the required > > operation in the memcpy_nt() function documentation should suffice. > > > > Ok, but again wouldn't it be arch specific? > AFAIK for x86 it needs to boil down to sfence, for other architectures - I don't know. > If you think there already is some generic one (rte_wmb?) that would always produce > correct instructions - sure let's use it. > > 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. 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.