From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0098.outbound.protection.outlook.com [65.55.169.98]) by dpdk.org (Postfix) with ESMTP id 118BF4A63 for ; Tue, 8 Dec 2015 18:49:50 +0100 (CET) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@caviumnetworks.com; Received: from localhost.localdomain (122.166.133.149) by BY1PR0701MB1723.namprd07.prod.outlook.com (10.162.111.142) with Microsoft SMTP Server (TLS) id 15.1.337.19; Tue, 8 Dec 2015 17:49:44 +0000 Date: Tue, 8 Dec 2015 23:19:27 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Message-ID: <20151208174922.GA1868@localhost.localdomain> References: <1449417564-29600-1-git-send-email-jerin.jacob@caviumnetworks.com> <1449417564-29600-2-git-send-email-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB97725836AD15BE@irsmsx105.ger.corp.intel.com> <20151208124527.GA18192@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836AD1BDB@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725836AD1BDB@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [122.166.133.149] X-ClientProxiedBy: BM1PR01CA0049.INDPRD01.PROD.OUTLOOK.COM (25.163.199.21) To BY1PR0701MB1723.namprd07.prod.outlook.com (25.162.111.142) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 2:YouMnQJGrm2k19Vj1Fhm1a6Tkfnqx2xh2/8F2BZPzsNGUf6pvwd8qnWF3YdL7rUCokJwv4GeHSIlJEowUEfgurECXXhgPWyXui7EGVWIlnwv7UCLIe2jgkjMj3T9//cX+o8JHMdWKKdBQM3lBQptzA==; 3:RyyFaylbpWUzlAYpolJUQrdSykKGPbQFkVojS3HB7VBvlmfnp782CJL6B30ZbgZ7tNSAHh9ZUj4D0lWhA7kJH/xLM1+mpKzuqfPqsnbj/aTdOpfspqRloZXlUMxlrTaR; 25:7VKelQ33HzeNR1XffxLy+Wr9FLQJyE+BGN2Gb042CXmUHKYJiUQaznONn/dLqzI43+Q5QTm9R8trOkUE35qeTS25Sefeu1NMB6rKBKOrizvn1JJv+rX01lPSHMF+5M2Do9g92qLLTt/F0J9G70VdIXfYRpK4TGAZmUcXhDz0GUPqrgAYLiWalxq9JVJr9HXmGtSjYNGQ7Oy6SU5LcFcFbbZ57Mea4aB15vERy8zE129+THkz7gvUSZA7zd0d2O0LOQB6jUS3+ZPkvA5YlcUfUg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 20:8qX5OoExp4fDz+MGgtem60yZA2EW9zLrkxzt5LuEAXq9CBgix3/o/q8eAXBQy0lsu6PmoAHvmMKj7F9AbufG5Xftfcf1esJfPcwLdL/ZfxzIfme45oIssYBzcIfyH1wnWQRFghpZXXzs7IF/HJtEr1sKQ0ZlTIMLA1P/BFLZBhmIdb8jFSfKV52ZpWnWV5IPxgihgjdXz+ODnCYa1+I1UgzFt5zCa/qR3prgR9j+2NG2mzA+SbX16smAR1CtAoHx3ntA6xe7t2U4s9T9wIGlRyjtSD6D7bsXcEYQQQNPKKGgrxX8zm4OJppPoo4Fj2MegYZEPeuw6pClczib3O7OJocsnbfQKSKe/EWvmT+jV5yC4ldrDj+zLW3CjDD75EW8bVnY7IvDd7eej0TDzSRSxCcIBUz1YLiDvazJh9QUHMnr+yBS2D6nqJ4jocLQPsQ8u4Y2+aHtBHqN2TQ4ZXk9JhaUIleRhEvudNn+ZhHVtRZqnGuaDffAHOQw4Tz/mGS67NATeZKYxwNNVbukNgSYhfSxZ+P3NVZiXm2+czdB7HupXRG9Km91veQWEIjERl/2VuOysWA9xYzfwl5WFujrv/vfS55TdJAFWiweb1V7DI0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(236414709691187); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR0701MB1723; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 4:VeMd+ey9ZXpYw8dc70HT7KffE1urpq2kn/sFwCPxsx/LpsB0oNZAzsP9SLdI98s7bukJZMcksvQrc8atXUWuSl716IMgKEDTQuqYtDB9LJAG8eleJzpJSB4CR1yDEwDSdw5a9cz8j07ZSDmN3CZuCDaS9NkFi16x50Pit8jqnq5NcKUB9Omc8TRiqlDJJY+lQ49z5lW9Y7vwiS3uiUWIAIBFjbBCeRmCFOK30zzxuLlZ0cpM/pGYo6kLzHIH0CgKFH+CBU+052P+yAIcl1J8QG89VhKtOlVEL2hQvz0gqLdMJibaaY3uqnevlnA3CK1/0xtPAGxnwRog5DOdQXsT6UY7M8l/ifNNS6yUlfdwE1ULQ/1CxcjuMaDMB9hy/QniJlRVDUzPDi10w5Vom8OibBKgTrCbyGPhYsv9FnIiLki3YE1lciaV8lyvQXsddgCS X-Forefront-PRVS: 0784C803FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6069001)(52314003)(13464003)(199003)(24454002)(189002)(377454003)(19580405001)(86362001)(6116002)(19580395003)(76176999)(1076002)(33656002)(54356999)(97756001)(101416001)(83506001)(2950100001)(40100003)(1096002)(50986999)(3846002)(5008740100001)(122386002)(23726003)(586003)(5004730100002)(87976001)(66066001)(105586002)(4001350100001)(5001960100002)(189998001)(77096005)(92566002)(50466002)(97736004)(93886004)(81156007)(110136002)(61506002)(42186005)(46406003)(47776003)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1723; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1723; 23:o053xjQzl8F0OY7rqrNzfw1zbJFF2v54zP4YgGI?= =?us-ascii?Q?28f5kM+MYfMtszvRUMljjiILWksAr/ZyOr21K3tr8vUBjIUlEbMTAzSpfs2B?= =?us-ascii?Q?KgqWfZ1DZt20o7+yC3S44V/pDd6Qn6UPuw6jKYm/F/popBzQej1wLlKDAB6h?= =?us-ascii?Q?i6tdEUZSoTEBDDtzCO120EAVRIsjT+WtCpEKhUTIj7/Fc7J+L1KueimkvHBE?= =?us-ascii?Q?rDNlbpIOIX+83VNW61e4UaO0n58mR58bFx/bmlQwrfPTn0X1fFXM/o8rm1/D?= =?us-ascii?Q?K98hLoQB388dCForKyY4keNNynOD09Y2WEZ916aDDwc5robDt82WgNJ3+xTJ?= =?us-ascii?Q?ucLObaE/UigcBfzrWIpZ7q/0poqXD9TiM76jPYECseHquxtOw+O1YDcITJGk?= =?us-ascii?Q?IaMOrOXmayjbooBJpMbHRjBVvjhJK/exktdkbFB0y8L1e8p29ur8UxGzV9Dq?= =?us-ascii?Q?Wsje1jy9PH2ePo8vZBLrmhKRmYFChiQ3X0cENB7EtBH5AfZ/Ls2O7OcWOisL?= =?us-ascii?Q?wmf84l3gIklPoaKPdCAuEsUEaPpWfVG8fzGzcWtl62DhGtBGN3q79uybxsRj?= =?us-ascii?Q?pzN1Df4mSR/7tnwA/sYImeFQcnXajZT5tNTIdTVksyY+GLibijyUKUFVg4qm?= =?us-ascii?Q?8i9PwF1AE7ht+sT0f0V8I4e+QJTEWbJ9IcJHWaC6jxFwdwNPLpCstuks905Y?= =?us-ascii?Q?SaXdXnncuaKWWvO7OZThfhaS8itnxP0XC33Zhz6eZr1EGAXFRJM5WEW5zoAI?= =?us-ascii?Q?8XI7AH75Z1UT/h+k9QG38v9YPXIhO2ZpXfec834Xf6cJ6VtDUdIXeMMFcHP9?= =?us-ascii?Q?0MCsIC1dRbC4OxYW05aS+DgbWh2qTVmcVOl1MFoHCSo6MEabIGaZHxHU6S1n?= =?us-ascii?Q?zEO6n6c9ro+SjMiK1ePKOLkrRaxshg+JT6rWJ+Zi3zz2+VJN7Pzz2L3VwkKc?= =?us-ascii?Q?y+M8NaWNndHK4HVtbVTn6+ZNyQyDChOd4QsfcS3d5WvQ4YmiV+hG9n5sDt0Y?= =?us-ascii?Q?NSZiAnKggsSsfjiWBpNjpuYKYV60+Ablo4o7iFXmzKJgfyd5rDqkAEd2DoVl?= =?us-ascii?Q?d0j8c9cpwvsyEiXqExyHlEWqEP7c1vSON0dp3TIxdbw/e/fogMRwFjDtzNks?= =?us-ascii?Q?7GOv7MHKHv1EFWwTPbIUmnoe/FD57ZA0Wio1nOws3AAQZCYzfDw7imlg2sFJ?= =?us-ascii?Q?wF7k7j8KwT8fwjI0o0vfYIa1HWRqnXEQlqjfD?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 5:ZS73OkQMF7ssLe3Xd5m9v6EyWzNeeAwlGSkSsUDaN8mtOdonSLmjF2+AQhdiWuAMrH8rEKwJ/HqvDykWHv/h7mqIxfvilbekeio68OwD4hjUR1bsqy3XarWeET4ot+2i7EjNp0poWfvyiEzZOlyJ6g==; 24:SaM92cbGd6+qmikCQosxzfNUA6VAVvV9lVumxPe2fvv5OxJAJuiynp5uj5dPiW2BSlJ+2LX6Ga2TMJRQxbiH5i66RlcrI+95MSkwNfEatwk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2015 17:49:44.4185 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1723 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:49:51 -0000 On Tue, Dec 08, 2015 at 04:07:46PM +0000, Ananyev, Konstantin wrote: > > > > Hi Konstantin, > > > > > Hi Jerin, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Sunday, December 06, 2015 3:59 PM > > > > To: dev@dpdk.org > > > > Cc: thomas.monjalon@6wind.com; Richardson, Bruce; olivier.matz@6wind.com; Dumitrescu, Cristian; Ananyev, Konstantin; Jerin > > > > Jacob > > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets > > > > > > > > No need to split mbuf structure to two cache lines for 128-byte cache line > > > > size targets as it can fit on a single 128-byte cache line. > > > > > > > > Signed-off-by: Jerin Jacob > > > > --- > > > > app/test/test_mbuf.c | 4 ++++ > > > > lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4 ++++ > > > > lib/librte_mbuf/rte_mbuf.h | 2 ++ > > > > 3 files changed, 10 insertions(+) > > > > > > > > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c > > > > index b32bef6..5e21075 100644 > > > > --- a/app/test/test_mbuf.c > > > > +++ b/app/test/test_mbuf.c > > > > @@ -930,7 +930,11 @@ test_failing_mbuf_sanity_check(void) > > > > static int > > > > test_mbuf(void) > > > > { > > > > +#if RTE_CACHE_LINE_SIZE == 64 > > > > RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE * 2); > > > > +#elif RTE_CACHE_LINE_SIZE == 128 > > > > + RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE); > > > > +#endif > > > > > > > > /* create pktmbuf pool if it does not exist */ > > > > if (pktmbuf_pool == NULL) { > > > > diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h b/lib/librte_eal/linuxapp/eal/include/exec- > > > > env/rte_kni_common.h > > > > index bd1cc09..e724af7 100644 > > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > > @@ -121,8 +121,12 @@ struct rte_kni_mbuf { > > > > uint32_t pkt_len; /**< Total pkt len: sum of all segment data_len. */ > > > > uint16_t data_len; /**< Amount of data in segment buffer. */ > > > > > > > > +#if RTE_CACHE_LINE_SIZE == 64 > > > > /* fields on second cache line */ > > > > char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE))); > > > > +#elif RTE_CACHE_LINE_SIZE == 128 > > > > + char pad3[24]; > > > > +#endif > > > > void *pool; > > > > void *next; > > > > }; > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > > > > index f234ac9..0bf55e0 100644 > > > > --- a/lib/librte_mbuf/rte_mbuf.h > > > > +++ b/lib/librte_mbuf/rte_mbuf.h > > > > @@ -813,8 +813,10 @@ struct rte_mbuf { > > > > > > > > uint16_t vlan_tci_outer; /**< Outer VLAN Tag Control Identifier (CPU order) */ > > > > > > > > +#if RTE_CACHE_LINE_SIZE == 64 > > > > /* second cache line - fields only used in slow path or on TX */ > > > > MARKER cacheline1 __rte_cache_aligned; > > > > +#endif > > > > > > I suppose you'll need to keep same space reserved for first 64B even on systems with 128B cache-line. > > > Otherwise we can endup with different mbuf format for systems with 128B cache-line. > > > > Just to understand, Is there any issue in mbuf format being different > > across the systems. I think, we are not sending the mbuf over the wire > > or sharing with different system etc. right? > > No, we don't have to support that. > At least I am not aware about such cases. > > > > > Yes, I do understand the KNI dependency with mbuf. > > Are you asking about what will be broken (except KNI) if mbuf layout IA and ARM would be different? > Probably nothing right now, except vector RX/TX. > But they are not supported on ARM anyway, and if someone will implement them in future, it > might be completely different from IA one. > It just seems wrong to me to have different mbuf layout for each architecture. It's not architecture specific, it's machine and PMD specific. Typical ARM machines are 64-bytes CL but ThunderX and Power8 have 128-byte CL. It's PMD specific also, There are some NIC's which can write application interested fields before the packet in DDR, typically one CL size is dedicated for that. So there is an overhead to emulate the standard mbuf layout(Which the application shouldn't care about) i.e - reserve the space for generic mbuf layout - reserve the space for HW mbuf write - on packet receive, copy the content from HW mbuf space to generic buf layout(space and additional cache misses for each packet, bad :-( ) So, It's critical to abstract the mbuf to support such HW capable NICs. The application should be interested in the fields of mbuf, not the actual layout.Maybe we can take up this with external mem pool manager. > > > > > > Another thing - now we have __rte_cache_aligned all over the places, and I don't know is to double > > > sizes of all these structures is a good idea. > > > > I thought so, the only concern I have, what if, the struct split to 64 > > and one cache line is shared between two core/two different structs which have > > the different type of operation(most likely). One extensive write and other one > > read, The write makes the line dirty start evicting and read core is > > going to suffer. Any thoughts? > > > > If its tradeoff between amount memory and performance, I think, it makes sense > > to stick the performance in data plane, Hence split option may be not useful? > > right? > > I understand that for most cases you would like to have your data structures CL aligned - > to avoid performance penalties. > I just suggest to have RTE_CACHE_MIN_LINE_SIZE(==64) for few cases when it might be plausible. > As an example: > struct rte_mbuf { > ... > MARKER cacheline1 __rte_cache_min_aligned; > ... > } _rte_cache_aligned; I agree(in last email also). I will send next revision based on this, But kni muf definition, bitmap change we need to have some #define, so I have proposed some scheme in the last email(See below)[1]. Any thoughts? > > So we would have mbuf with the same size and layout, but different alignment for IA and ARM. > > Another example, where RTE_CACHE_MIN_LINE_SIZE could be used: > struct rte_eth_(rxq|txq)_info. > There is no real need to have them 128B aligned for ARM. > The main purpose why they were defined as '__rte_cache_aligned' - > just to reserve some space for future expansion. makes sense > > Konstantin > > > > > > > > Again, #if RTE_CACHE_LINE_SIZE == 64 ... all over the places looks a bit clumsy. > > > Wonder can we have __rte_cache_aligned/ RTE_CACHE_LINE_SIZE architecture specific, > > > > I think, its architecture specific now > > > > > but introduce RTE_CACHE_MIN_LINE_SIZE(==64)/ __rte_cache_min_aligned and used it for mbuf > > > (and might be other places). > > > > Yes, it will help in this specific mbuf case and it make sense > > if mbuf going to stay within 2 x 64 CL. > > > > AND/OR > > > > can we introduce something like below to reduce the clutter in > > other places, macro name is just not correct, trying to share the view > > > > #define rte_cacheline_diff(for_64, for_128)\ > > do {\ > > #if RTE_CACHE_LINE_SIZE == 64\ > > for_64; > > #elif RTE_CACHE_LINE_SIZE == 128\ > > for_128;\ > > #endif > > > > OR > > > > Typedef struct rte_mbuf to new abstract type and define for 64 bytes and > > 128 byte [1] some proposals list. > > > > Jerin > > > > > Konstantin > > > > > >