From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0050.outbound.protection.outlook.com [104.47.41.50]) by dpdk.org (Postfix) with ESMTP id 7D4B31CE07 for ; Fri, 6 Apr 2018 03:26:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VoN/0sqsPR7if+E7e1L2pivs0wn8DCrix4DaH5FKtG0=; b=XUNz95qtZ0QzLC7ab898W20UjdyLej3HagOJTGm7jFnjcb37KRx0Ry8nF5jATXPZXmgr5eB2IIVdzOZimhAWveoxDzOC9dRsaIdQaosuxAqZCXzOi0fRQA96EOUQQtDIKRjAHJMUwwOIXYwbCAk1oFgNYY4Wpou1qNIts4nOQIM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (12.108.191.226) by BN3PR07MB2513.namprd07.prod.outlook.com (2a01:111:e400:7bbf::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 01:26:34 +0000 Date: Fri, 6 Apr 2018 06:56:26 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: Olivier Matz , "dev@dpdk.org" , "Richardson, Bruce" Message-ID: <20180406012624.GA12155@jerin> References: <20170630142609.6180-1-olivier.matz@6wind.com> <20180403132644.23729-1-olivier.matz@6wind.com> <20180403150722.GB15937@jerin> <20180403152517.hsjghkj5z6mauze7@platinum> <20180403153703.GA19072@jerin> <20180403155601.rqb7fhu6vggzrh7e@platinum> <20180403163254.GB19072@jerin> <2601191342CEEE43887BDE71AB977258A0AB90E3@irsmsx105.ger.corp.intel.com> <20180405080134.GA2674@jerin> <2601191342CEEE43887BDE71AB977258A0AB9930@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB977258A0AB9930@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [12.108.191.226] X-ClientProxiedBy: CO2PR04CA0083.namprd04.prod.outlook.com (2603:10b6:102:1::51) To BN3PR07MB2513.namprd07.prod.outlook.com (2a01:111:e400:7bbf::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cbcf011e-2415-4929-a893-08d59b5d70c2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 3:H9psboGf0pLexpOKYVPNRMCWSEiOF5ftoQAgleMLuQW4oxwFLkGcPlYHADBQs44oImpD3HOhF2VrkNap61wiZJCuwMSzIzag4qVxt/CpnQ+rPiY/NSa80APNeW/M3oaxT/FXb94tXiNvdSLHL2XClL4w7YpN/tYIGTQ/iQ7DVrX+91L9iY19YFHgo7yXVjUXeiq6kkgB6XgXJWJjOiGmgnxAULe0vX80BrYW6oJn4JUu4Kan++g8a++Xm5PwUXNT; 25:pX6OssYZekn4PVNAgutIoYK0BNYiFBhx2L4jHKwKXKCc+i0fqJR0ib3Qzk3Ud5nmDWw5g7m+CneCbKyo0DsF0k4GuBdBrZQE3p5P6ogVJ1vqV3Vf70tagccTapB91dgLOpo+JaFs/pT1d9ocSbkjNTNN6zx6/vkOjb9rnD9a9oG3P5mtAX5aJZ8sNJgKYVgzch/hykifk9vMuHZEYZ3Bbsv/xVgMtJBPjvZ0ODqIQDDX8odOI7B70uACmNA4dqJigIE+DJoyW1mKoHafWIuHh23HAJgQ/XvntlT437a8UUtZrAE8Nqc+6eTSSUl5MP+NIXhOgdX00rTNrRLCevIzAA==; 31:jzjfHVanOY2RUvK89nDFvj8pZIOg8ZL+qowGHXOhtN9/CS6LCQhBV0Lteq0hCRUgWwMEBWDXv2Cm82tYxKShLIB6eOYxEodNuxGiI5Lt0Vj7MtInHha0/6M6UknsEkiVtzj4uj8l0W2/nKow4D/pjovsrNEOSCaH9PXQSJ3VETY4syM1XBzMlIoASfSekm4BsX6eIjsh6ui4V2mFPtdoCoKbkRa2wWx2fgXxNioVP90= X-MS-TrafficTypeDiagnostic: BN3PR07MB2513: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 20:PCV7N/YnwQN8dX1V6MtZ0guZT5qOla5+kWzqA0XugzV414Hbwdj2llftQCe2JLfTDOWiodcSHFsn4DsPEDdlT0j2yQau0bwWq/lM7/CIBBstAXF1LpkcboIunIgvPADtlhS7KCFN/HSa1peOKgcTuyugf3YBrNqRs3pk3zY5zApayiTP3SbFTyCVqEQxzuunthni4WRl018HIy85N2nq5UQo2JRG7HeQe/mvXZwNVFw6Sbxd4h97YYhpMdKDSP9SwLKY3AJveqyWwXF4aW2nDHRr4BboaESoHk5A4/LQEi1+cubxxbE9E93v+kYCtLytF9NuSn40AdcP3Imzk+yv+PjtSHD0wtZdwV6aFmp6aO8pKbBxh/7skyrHE0rawdvEsowKUqIS3s1QYADr8EHW9a1Y04rwPe4nb+yfwvyN00QEVCJs0OjuSaySKFTMss3Gl8rM6eYd1akXHIkZ0DVOyJqbWHZYVtTpCSForZQNJ5U70UlbDa+npqm3PM/pipKdZBYkV2+vUIMShllr1MHALQ9ckENJWYEbBlb5LqPgw1vigBrtAl/D81XxLErIweuvEadhTh07da2rA0hoZaJKLzwu+necQjMAQlZymKNkJFU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501327)(52105095)(93006095)(10201501046)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BN3PR07MB2513; BCL:0; PCL:0; RULEID:; SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 4:5L6zeF0OAclfOBlAnahfwdr6uzW4u0BVuSqv3lj6FMNaLQU2pg+pnCIuxrWewvRoayuU5DaSvXRxPJPw34uRAwqTJuTudD4jFbCXBD5Tdo3w43tH9j9DXi3CHnBEbKH1N4v/YNH1sKGj5ytb/4Y00Ve9mck5gw2vb3I2tMoYWd+9jiGrCPgaSaG4pRu/9jb8LHncKNzQFXsO39okNStDbllPsrHH3aT5pV/2I0M9YzpwG6P4rRCP09vhhus79avYgowyXsBLcGEdKAU3/7URb6e0+NezGtRXb+CCOcGMT3Xxn5P1276owB2N9AX8L8aTLx97BEMgX5JQAuuy0vWtzIbewaTPb8qilMGlJR4LyAI= X-Forefront-PRVS: 0634F37BFF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(396003)(376002)(366004)(39380400002)(189003)(199004)(13464003)(68736007)(16526019)(446003)(305945005)(956004)(16586007)(26005)(186003)(8676002)(50466002)(4326008)(5660300001)(7736002)(33656002)(97736004)(58126008)(6496006)(53546011)(11346002)(55016002)(33716001)(81156014)(52116002)(316002)(81166006)(105586002)(106356001)(72206003)(386003)(8936002)(33896004)(6666003)(2906002)(6916009)(3846002)(6246003)(575784001)(1076002)(54906003)(66066001)(23726003)(478600001)(25786009)(229853002)(53936002)(42882007)(486006)(6116002)(47776003)(93886005)(59450400001)(9686003)(476003)(76176011)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2513; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR07MB2513; 23:+paA/NpiiyKA1x2MzKk1fXzy9agr4c2bQm7fCHNd2?= =?us-ascii?Q?cq2BWc/j4qHdueltC7VkJQbDtldggHEvhOGykOuAZX4le7ae5CkTbrMXPG1C?= =?us-ascii?Q?GqP7N8arOpwlMcyfM660yEc6LltqeBbnz73PZBpTRvG29/q+0rDdSRQ7ZbWv?= =?us-ascii?Q?NlNKBfvkztOcyqSHuD024PuxJEo8AVtZglEe0nSp7tB2+oAoE77Wcf481UjV?= =?us-ascii?Q?e08O7pJzuYPWZ9bWLm0S7sDBnz9lgLF6+U34F7kbWWVR20uapA5A6oYnl3wb?= =?us-ascii?Q?yRkHmQXDX/W4rUKiMA6tCzSPGhTyKdAK8vvBwS1Uac3DpbACXds+3ziJp8Xb?= =?us-ascii?Q?vDhRYChsGjy+CCeJHyaqCnY46krvWjY74nGPWAXwVpeiOR/yanrRkAm2eBrz?= =?us-ascii?Q?xE5tzieSeQd6sKRcD41g6ofiMHM1bx2s4FdM9U8S71mfce8NEqWqVseG3Z4J?= =?us-ascii?Q?KhycCjA4GdTegpYHLU7zUyiZqaGc/pFaFj1rUM14AIbEjHt+71rhRQmKdIdF?= =?us-ascii?Q?4wgVz0bXctEtVfRtXI7gsZNDWxHocjdLYbydmP5wskQaOKlelpIOqQmq4CTL?= =?us-ascii?Q?1SpR//x1dZnSwhgSidzXH0MOa1LtQqToHpZ42+kOUha1W8zYC5x3uM5Ssm3g?= =?us-ascii?Q?xLxo2P0F8v3CGok6DCOiy6FWuRSBHa3XNGLUupqBjZvaWSazJyfDIuHizoDp?= =?us-ascii?Q?wSrdt1dIcqVpi87tr5P/ey1qxY+yrTXUM+aNi776nGcEg7ayHfZZtVL2JwWd?= =?us-ascii?Q?DqIJSFmuxvOGMIhPQuGvUteDyvrzg0WjvQ/Re9TyHG5EtIizsz4DilhzjPoA?= =?us-ascii?Q?KOihOUFR9OX1CI+5fueqI5mo12VwXxBWPDWoHauQmZFe4IhPZXtr3kKvdsGe?= =?us-ascii?Q?LDrM5uipDaOzXJFwxsEwyKUtDzTLL3Ja3Hg2+JihtxgnQ48ZvJPgFgnEcTuF?= =?us-ascii?Q?hsUBnw8t+w05pqnZNsIXCbfqQmaEn5UETkJb6ROr+uC349PD9Vj2kVrctXCb?= =?us-ascii?Q?TcmPK7yv7AodvbBV0sVK3eIGq0svR6NPeXjB7wDheDOwtSD3vZFs4h8T+0jQ?= =?us-ascii?Q?miLvjxsj3VZYVWpVn5bqLuCaAWrMg+aGEtF286j1BKWTPDmT8mlD5eDqPxTH?= =?us-ascii?Q?c9W/kvlCqIswZlZJ6Usu6P8JUIqexCTt1KQNFaHXPHTPM2neFb5PTXyjNUN/?= =?us-ascii?Q?F75q/i0AwCT6T17/RwpreGGsNJuXPZk58+8Msbq8FkP2wglzHihQXz2zIbAY?= =?us-ascii?Q?RFBypaz/pYpnbaiI2jlhH1q6hPXKvR7W3/udEfjwX8Qmg2M4l940mieuwFQL?= =?us-ascii?Q?T4xfhTYvG5FOuC9ouAQaivdwu0mXKVb6vdNhv19zMCaLoDMjBuLoAUeItS7W?= =?us-ascii?Q?Ra7qZdkvp2kxojoiHZpDycGUx7H08diPdRFYDNwtIQNUO2WXXucj/r72/th4?= =?us-ascii?Q?LsqZNqUhA=3D=3D?= X-Microsoft-Antispam-Message-Info: ScCB4fepgfIdP9X5AtOmRcd2RHMT0W03n5hNCI9Pr/BtZogMEjBvY8VC/wrJ7/jMmGoXbKtbEFJhQRTPJ3TjaSEqhn0TA/3/8JThEwYg1ftrU8Vf4TMUvkYF441ow+yFuCBrThtdHukRlSWZH/e8jE25hRu3sw6Ho6ttiUMEoRYP8dWmL+2x4T4X5uSc+XOZ X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 6:KKVjHptAm0Pv0+jTQnN4D4BcNnbPMFB7TrgjL0SkdeEw8E+hmR5GctjGLj09QbQ2beFXqvd7qoNzTu7MRDDrIlEzPr7xpLu5wKJ2uyRY9qe6YrarxFryEsVwfiqSfJaNyIeTPcyMUc6AmL8+6yV7vQ0diQhi3DeGMdTx/9RQ40rzcTjw60GLv8r1Qfo0iD/L80iob4dWPBWk/StDjyoPFRPWQdYakr1Bp0T7HZDID1M1gclhfRMRmJN+HCkfctgR0Zenlphtrnne07Q2CiFdmBpiqpfMi/aL+pY0g8FiaBpRO9Qs1fuBaxvjyITqfyLkpGRvbrWLxZKIdBszBVOitJgxMOp1cKDN505iqfE+gf4HDiC8P3kdmJJwY+n4LuIIlDlSHuAQ1BSYCvRhzm81gQ0ULxgLFpm/9iRCcnrl5nInL+DU0NWHJ39HclLowt8Fxz/KRFxYE8FBmzKihnVMcA==; 5:lirYCRGNKlJ2+q/Y2+o2pzGJsLLqokXewA7EN/xcY1Aun+MgpFfJiSv2T2HdJ9Wafm/hdFwqLdY7+z7dOPhRy8d12jw7h0nxqrQxh2uCeex4iIsBGLAW3ImwDc5Bmt6MDaXjy9YbCO7BxB4sr6B1KTRr1eRfwePoOKUsWEHxACA=; 24:DPPikK98Fe119jJaluSrzDxEsmxRDBPTz/rp/mu1gPz6Ch+PBOpZt4AwOX7kcJ0igrKDKLKDK2oOnrmIloFQ5o5dmgpp0lAF5LzY1A/jHD8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 7:nysHHhLfLn52EkOS6m3NUrqQ0JM75NbYEUlhL+53fB9584Y+odQ9NNM4cduFENBG+qlO420Wcma50Bdpf4h8QmbEtr6IFlhsIGhn3L8gZ8jqd7VFO7/j5fBeLUrEEEGlRnnkqYWk/0LuolY6XmLbzUwrdsklUTO/Dwi9LB9FI8nMr15gEB8flzrNHx932xSYAjMgfWpZq1yHEzBpx/bk/QEf71wlElE7Zp9/UQ3KQTJyRmg5GtbtB0ilFgWQxgvt X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2018 01:26:34.2289 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cbcf011e-2415-4929-a893-08d59b5d70c2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2513 Subject: Re: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring structure 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, 06 Apr 2018 01:26:39 -0000 -----Original Message----- Hi Konstantin, > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Thursday, April 5, 2018 9:02 AM > > To: Ananyev, Konstantin > > Cc: Olivier Matz ; dev@dpdk.org; Richardson, Bruce > > Subject: Re: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring structure > > > > -----Original Message----- > > > Date: Wed, 4 Apr 2018 23:38:41 +0000 > > > From: "Ananyev, Konstantin" > > > To: Jerin Jacob , Olivier Matz > > > > > > CC: "dev@dpdk.org" , "Richardson, Bruce" > > > > > > Subject: RE: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring > > > structure > > > > > > Hi lads, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Tuesday, April 3, 2018 5:43 PM > > > > To: Olivier Matz > > > > Cc: dev@dpdk.org; Ananyev, Konstantin ; Richardson, Bruce > > > > Subject: Re: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring structure > > > > > > > > -----Original Message----- > > > > > Date: Tue, 3 Apr 2018 17:56:01 +0200 > > > > > From: Olivier Matz > > > > > To: Jerin Jacob > > > > > CC: dev@dpdk.org, konstantin.ananyev@intel.com, bruce.richardson@intel.com > > > > > Subject: Re: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring > > > > > structure > > > > > User-Agent: NeoMutt/20170113 (1.7.2) > > > > > > > > > > On Tue, Apr 03, 2018 at 09:07:04PM +0530, Jerin Jacob wrote: > > > > > > -----Original Message----- > > > > > > > Date: Tue, 3 Apr 2018 17:25:17 +0200 > > > > > > > From: Olivier Matz > > > > > > > To: Jerin Jacob > > > > > > > CC: dev@dpdk.org, konstantin.ananyev@intel.com, bruce.richardson@intel.com > > > > > > > Subject: Re: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring > > > > > > > structure > > > > > > > User-Agent: NeoMutt/20170113 (1.7.2) > > > > > > > > > > > > > > On Tue, Apr 03, 2018 at 08:37:23PM +0530, Jerin Jacob wrote: > > > > > > > > -----Original Message----- > > > > > > > > > Date: Tue, 3 Apr 2018 15:26:44 +0200 > > > > > > > > > From: Olivier Matz > > > > > > > > > To: dev@dpdk.org > > > > > > > > > Subject: [dpdk-dev] [PATCH] ring: relax alignment constraint on ring > > > > > > > > > structure > > > > > > > > > X-Mailer: git-send-email 2.11.0 > > > > > > > > > > > > > > > > > > The initial objective of > > > > > > > > > commit d9f0d3a1ffd4 ("ring: remove split cacheline build setting") > > > > > > > > > was to add an empty cache line betwee, the producer and consumer > > > > > > > > > data (on platform with cache line size = 64B), preventing from > > > > > > > > > having them on adjacent cache lines. > > > > > > > > > > > > > > > > > > Following discussion on the mailing list, it appears that this > > > > > > > > > also imposes an alignment constraint that is not required. > > > > > > > > > > > > > > > > > > This patch removes the extra alignment constraint and adds the > > > > > > > > > empty cache lines using padding fields in the structure. The > > > > > > > > > size of rte_ring structure and the offset of the fields remain > > > > > > > > > the same on platforms with cache line size = 64B: > > > > > > > > > > > > > > > > > > rte_ring = 384 > > > > > > > > > rte_ring.name = 0 > > > > > > > > > rte_ring.flags = 32 > > > > > > > > > rte_ring.memzone = 40 > > > > > > > > > rte_ring.size = 48 > > > > > > > > > rte_ring.mask = 52 > > > > > > > > > rte_ring.prod = 128 > > > > > > > > > rte_ring.cons = 256 > > > > > > > > > > > > > > > > > > But it has an impact on platform where cache line size is 128B: > > > > > > > > > > > > > > > > > > rte_ring = 384 -> 768 > > > > > > > > > rte_ring.name = 0 > > > > > > > > > rte_ring.flags = 32 > > > > > > > > > rte_ring.memzone = 40 > > > > > > > > > rte_ring.size = 48 > > > > > > > > > rte_ring.mask = 52 > > > > > > > > > rte_ring.prod = 128 -> 256 > > > > > > > > > rte_ring.cons = 256 -> 512 > > > > > > > > > > > > > > > > Are we leaving TWO cacheline to make sure, HW prefetch don't load > > > > > > > > the adjust cacheline(consumer)? > > > > > > > > > > > > > > > > If so, Will it have impact on those machine where it is 128B Cache line > > > > > > > > and the HW prefetcher is not loading the next caching explicitly. Right? > > > > > > > > > > > > > > The impact on machines that have a 128B cache line is that an unused > > > > > > > cache line will be added between the producer and consumer data. I > > > > > > > expect that the impact is positive in case there is a hw prefetcher, and > > > > > > > null in case there is no such prefetcher. > > > > > > > > > > > > It is not NULL, Right? You are loosing 256B for each ring. > > > > > > > > > > Is it really that important? > > > > > > > > Pipeline or eventdev SW cases there could more rings in the system. > > > > I don't see any downside of having config option which is enabled > > > > default. > > > > > > > > In my view, such config options are good, as in embedded usecases, customers > > > > can really fine tune the target for the need. In server usecases, let the default > > > > of option be enabled, no harm. > > > > > > But that would mean we have to maintain two layouts for the rte_ring structure. > > > > Is there any downside of having two configurable layout? meaning, we are not > > transferring rte_ring structure over network etc(ie no interoperability > > issue). Does it really matter? May I am missing something here. > > My concern about potential compatibility problems we are introducing - > library build with 'y', while app wit 'n', or visa-versa. Got it. > I wonder are there really a lot of users who would be interested in such savings? > Could it happen that this new option would sit here unused and untested? OK. Fair enough. I have no objections for Olivier patch. As a suggestion, may be we can move "char name[RTE_MEMZONE_NAMESIZE]" in the struct rte_ring in place of " empty cacheline" to save 32B. No strong option though. > Konstantin > > > > > I was thinking like this: > > > > in config/common_base: > > CONFIG_RTE_EAL_HAS_HW_PREFETCH=y > > > > #ifdef RTE_EAL_HAS_HW_PREFETCH > > #define EMPTY_CACHE_LINE char pad0 __rte_cache_aligned > > #else > > #define EMPTY_CACHE_LINE > > #endif > > > > struct rte_ring_headtail { > > .. > > .. > > char pad0 __rte_cache_aligned; /**< empty cache line */ > > struct rte_ring_headtail prod __rte_cache_aligned; > > EMPTY_CACHE_LINE > > struct rte_ring_headtail cons __rte_cache_aligned; > > EMPTY_CACHE_LINE > > } >