From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by dpdk.org (Postfix) with ESMTP id 7E2FB5323 for ; Fri, 9 Jun 2017 19:16:34 +0200 (CEST) Received: by mail-pf0-f177.google.com with SMTP id 83so30542652pfr.0 for ; Fri, 09 Jun 2017 10:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HiRcLgg5BM5uY1UbuILiYl3LcHAYfmOUWJhHlemqPyw=; b=nUwPr2FG8zP3kyDFI97LxELwk25dk/Lg7U2zKj0FETbIZMtbJOpk4GtxlTNfqtUBfz DZQmjScdVvfcbPUTgTF62j4+BHynL9A8M6OX7Wj0g1Cb70dl99IJqxc3KN8yd72wS15N ogbCbhcEd3Q+ugE5veAl94WuHCpqZApwoycf7Fba4oiGc6/h3PQ6edgA1gr/LTU+Mcm6 kOdPBIsMWtQkiNVM2WOvjsiBY5z+1JwAor24kSmhFfD0m5pLIPrpWkeAly4tI53amyVH D88EIPLwVEOfybaIXfkuRincSfjOIXjK7VIMZyNl0EQxiGEmpx82Rcx882qcoa8ay/Fs oF0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HiRcLgg5BM5uY1UbuILiYl3LcHAYfmOUWJhHlemqPyw=; b=pus6TMYlkP717MRVVj7zkRRklgMOz1FEXVf3egk7afc8AfdqGnsFvWxCxuvVs2Y98W Cmf1Rm56Vu55lTNQq9V0uKDTrRgen3fB0QbPpB8CzUpyqhByngdNPls96Yh74BWGgNfI dto1t8Fq/C2wTJthQIxepFzRKCF4hKwoxWbSlMeZjLLsQLiQprctCNVsKiyd4Lzwxj9x H81Uu/PcC1RjwM3HKGjnuDGMABqDItQ7dMTvxVOhDA+JL2fz2IXwo6HGcCka4t9xOQli uz08Wuwmjoq97Q2YexiqDxZTT4jUvoydjBUlEvPLNnqyTBmGtFlPcXKb/wT0dkFRR4zw Cnvw== X-Gm-Message-State: AODbwcBCIBEpIJE7As1ib1XERtIMU5f6RTau9sX87QxRrQz6+gBGVja0 d+bM76LCjx7/3/GH X-Received: by 10.98.204.150 with SMTP id j22mr43311029pfk.236.1497028593433; Fri, 09 Jun 2017 10:16:33 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id g70sm4164520pfc.47.2017.06.09.10.16.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Jun 2017 10:16:33 -0700 (PDT) Date: Fri, 9 Jun 2017 10:16:25 -0700 From: Stephen Hemminger To: Yerden Zhumabekov Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "Verkamp, Daniel" , "dev@dpdk.org" Message-ID: <20170609101625.09075858@xeon-e3> In-Reply-To: <6908e71a-c849-83d3-e86d-745acf9f9491@sts.kz> References: <20170602200337.50743-1-daniel.verkamp@intel.com> <20170602201213.51143-1-daniel.verkamp@intel.com> <2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB05216@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB060FD@IRSMSX109.ger.corp.intel.com> <20170606124201.GA43772@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB0644D@IRSMSX109.ger.corp.intel.com> <6908e71a-c849-83d3-e86d-745acf9f9491@sts.kz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation 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: Fri, 09 Jun 2017 17:16:34 -0000 On Fri, 9 Jun 2017 18:47:43 +0600 Yerden Zhumabekov wrote: > On 06.06.2017 19:19, Ananyev, Konstantin wrote: > > > >>>> Maybe there is some deeper reason for the >= 128-byte alignment logic in rte_ring.h? > >>> Might be, would be good to hear opinion the author of that change. > >> It gives improved performance for core-2-core transfer. > > You mean empty cache-line(s) after prod/cons, correct? > > That's ok but why we can't keep them and whole rte_ring aligned on cache-line boundaries? > > Something like that: > > struct rte_ring { > > ... > > struct rte_ring_headtail prod __rte_cache_aligned; > > EMPTY_CACHE_LINE __rte_cache_aligned; > > struct rte_ring_headtail cons __rte_cache_aligned; > > EMPTY_CACHE_LINE __rte_cache_aligned; > > }; > > > > Konstantin > > > > I'm curious, can anyone explain, how does it actually affect > performance? Maybe we can utilize it application code? I think it is because on Intel CPU's the CPU will speculatively fetch adjacent cache lines. If these cache lines change, then it will create false sharing.