From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 5AD93255 for ; Tue, 23 Jan 2018 11:16:57 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 02:16:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,400,1511856000"; d="scan'208";a="168408631" Received: from rhorton-mobl1.ger.corp.intel.com (HELO [163.33.230.81]) ([163.33.230.81]) by orsmga004.jf.intel.com with ESMTP; 23 Jan 2018 02:16:55 -0800 To: Andriy Berestovskyy , "Van Haaren, Harry" References: <16d055c21f6c9e3788fff1a9ecef12d1449d7305.1516373253.git.aber@semihalf.com> Cc: "dev@dpdk.org" From: Remy Horton Organization: Intel Shannon Limited Message-ID: <14e524b4-b844-63ef-b686-6bddf468a464@intel.com> Date: Tue, 23 Jan 2018 10:16:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] keepalive: fix keepalive state alignment 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: , X-List-Received-Date: Tue, 23 Jan 2018 10:16:57 -0000 On 22/01/2018 18:20, Andriy Berestovskyy wrote: [..] > On Fri, Jan 19, 2018 at 6:31 PM, Van Haaren, Harry > wrote: >> These changes do reduce false-sharing however is there actually a >> performance benefit? A lot of cache space will be taken up if each >> core requires its own cache line, which will reduce performance >> again.. it's a tradeoff. [..] > 2. The original code (prior e70a61ad50ab "keepalive: export states") > had each element aligned to the cache line, not the whole array. Aligning each flag element was the original intention, so I see no issue in restoring it. The monitoring core only reads the entries within state_flags for which the corresponding active_core is set, so ultimately the trade-off in cache line usage is one made by the application when it decides which cores need monitoring. ..Remy