From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6061FA04CC; Mon, 21 Sep 2020 15:27:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4164A1D977; Mon, 21 Sep 2020 15:27:41 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id D49261D972 for ; Mon, 21 Sep 2020 15:27:39 +0200 (CEST) IronPort-SDR: A5VTMGZnrr73zGUtM7EsUlPmxyZw/RDSXJudffkWxyMdzFEaRqskTKSZ6ObPzbYw2Tt1deIzY2 M3x92aHbnNQw== X-IronPort-AV: E=McAfee;i="6000,8403,9750"; a="224523405" X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="224523405" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 06:27:37 -0700 IronPort-SDR: LWb2KI0FQFrjx1lU9w+HMEtTZ+RgKYiyP06EeLvKul3DvugabLiSyVRUpSyVebEeWWAyWFerF4 rk40SDhPtgZA== X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="309032518" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.217.64]) ([10.213.217.64]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 06:27:36 -0700 To: "Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)" , Phil Yang , Honnappa Nagarahalli , "dev@dpdk.org" Cc: Ruifeng Wang , nd References: <1599802699-20876-1-git-send-email-phil.yang@arm.com> From: Ferruh Yigit Message-ID: <7b2291ea-d680-e508-0802-f9337a43b172@intel.com> Date: Mon, 21 Sep 2020 14:27:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/memif: relax barrier for zero copy path X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/21/2020 1:21 PM, Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco) wrote: >>>>> >>>>> Using 'rte_mb' to synchronize the shared ring head/tail between >>>>> producer and consumer will stall the pipeline and damage >>>>> performance on the weak memory model platforms, such like aarch64. >>>>> >>>>> Relax the expensive barrier with c11 atomic with explicit memory >>>>> ordering can improve 3.6% performance on throughput. >>> >>> My question here is: `rte_mb` is supposed to make sure that head/tail >>> pointer are not updated before the packets are written into shared >> memory. >>> Does the atomic ensures that the packets are written into shared >>> memory before head/tail pointers are updated? >> >> Yes, it does. >> The atomic store-release acts as a one-way barrier here to make sure all the >> memory accesses before the store-release are observed before it. > > Ok then, since the sync is there and the rest seems fine to me. > > Thanks, > Jakub > > Reviewed-by: Jakub Grajciar > Applied to dpdk-next-net/main, thanks.