From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e_zhumabekov@sts.kz>
Received: from mgw.gov.kz (mgw.gov.kz [195.12.113.254])
 by dpdk.org (Postfix) with ESMTP id B087A2BB8
 for <dev@dpdk.org>; Fri,  9 Jun 2017 14:47:44 +0200 (CEST)
Received: from sts.kz (mail.sts.kz [178.89.4.9])
 by mgw.gov.kz  with ESMTP id v59ClhU6012576-v59ClhU8012576
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT);
 Fri, 9 Jun 2017 18:47:43 +0600
Received: from [172.20.19.72] (unknown [178.89.4.11])
 by sts.kz (Postfix) with ESMTPA id 05A415AA4;
 Fri,  9 Jun 2017 18:47:43 +0600 (+06)
DKIM-Filter: OpenDKIM Filter v2.11.0 sts.kz 05A415AA4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sts.kz; s=mail;
 t=1497012463; bh=RR5IUBZG2AaD4ZUMbPMeRkgXfAXJO7tN6ycol7rNwXc=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To:From;
 b=G5qfu5hMRwNyMxq0B2+1gdLgbNtFqSz+Dkvz+tE+JT1OF1D7NXA+SatOJrbW6ZElk
 g7jSuG3zkmY3EenMlBnuYSid/zPDV8fg4Wi3M85Og0+2apHWnd9YD6ixOJIKaEPjhs
 Y4M0U2Y/j8XpwCDUAMs3lmYbjzmSHLjR/4GC4lYc=
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "Verkamp, Daniel" <daniel.verkamp@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
References: <20170602200337.50743-1-daniel.verkamp@intel.com>
 <20170602201213.51143-1-daniel.verkamp@intel.com>
 <2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com>
 <A5F28D4A728A7E41839CDC5C3B5A01E87EA1B586@FMSMSX103.amr.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583FB05216@IRSMSX109.ger.corp.intel.com>
 <A5F28D4A728A7E41839CDC5C3B5A01E87EA1CBE9@FMSMSX103.amr.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583FB060FD@IRSMSX109.ger.corp.intel.com>
 <20170606124201.GA43772@bricha3-MOBL3.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583FB0644D@IRSMSX109.ger.corp.intel.com>
From: Yerden Zhumabekov <e_zhumabekov@sts.kz>
Message-ID: <6908e71a-c849-83d3-e86d-745acf9f9491@sts.kz>
Date: Fri, 9 Jun 2017 18:47:43 +0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB0644D@IRSMSX109.ger.corp.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2017 12:47:45 -0000

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?