From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0060.outbound.protection.outlook.com [104.47.33.60]) by dpdk.org (Postfix) with ESMTP id 598F92BA1 for ; Mon, 4 Jul 2016 14:46:05 +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=h7X+JlYnGPhCsXbcrL/uZ7f4aXmWjbSyHad/VoExg/A=; b=WXAklpr5jPW3b5ql+Gfp5NDzJi5OpqDm02aep8QR2GmWYlvHB8DEVAh4WelbiF0qQbCvBOVGygiBhgfpdPJL0x4fro2gbb0HNZ0mnpcL7caGQii1aofnMkzZQCI+WxVEVkqDnekw+h+kzoN+F9wlr/ZqCD/isR6V/85JW93qFgM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.167.47.22) by BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 4 Jul 2016 12:46:01 +0000 Date: Mon, 4 Jul 2016 18:15:41 +0530 From: Jerin Jacob To: Olivier Matz CC: Thomas Monjalon , "Ananyev, Konstantin" , "Richardson, Bruce" , , "viktorin@rehivetech.com" , "jianbo.liu@linaro.org" Message-ID: <20160704124540.GA5788@localhost.localdomain> References: <1463579863-32053-1-git-send-email-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB97725836B5AB67@irsmsx105.ger.corp.intel.com> <20160519133548.GA5308@localhost.localdomain> <9650772.iYDeGtr74X@xps13> <5742E752.3090207@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5742E752.3090207@6wind.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [122.167.47.22] X-ClientProxiedBy: PN1PR01CA0034.INDPRD01.PROD.OUTLOOK.COM (10.164.137.41) To BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) X-MS-Office365-Filtering-Correlation-Id: e7b4ad39-390c-4956-2933-08d3a4092948 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 2:5zx0E+85ziEEOoVHcOP9NVnYhC+RqCf/wsaLXrCiO1A/NLU/RXo539QoMnXZxqI56qQQ3KaRfR2Z6hzChyrZnsgTrMlojMSpgtfUv9LyjBw9VFASYqKFYASttaBYPCnEJaJIOffpO+tQ2gZrQy0xzyod4yeNh9sS2Jze+7Ic11B/0rTf0Eo1yCPGeiNAlU4/; 3:ETHIyg2ts/WC0kLufitEBYU4zy6AHWNsLq95o30GG5VBf6IIahDudtAMYxBjVisQQEED4K9nPqlNlJfcHvp7mGT4TVYiUQgz7A0wA/v96fhUM7Fl3ZgSc7zJ9umya3u5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 25:vZqC5FIC9aPl9IeY/jM2BkFgRqbT12B+7we0RaHjUlGX4OGDx/jS8yMtaP2D2evPCsGKgHWvO+pnKOahnowUfGfuHGOZXhpDirPF9v88qwaSSn10n5ZEknWyubCcaW9EvTzIh/I2gnmczJjSWlxn0eKJ3aTZq2EyKEinN65bx9IS9opTTcM8HNqYgMRa3uUCsFhYH0jw6qOhjEzrmPekhnQApcvav3PSNdgOTR3MqnDPAybg40ib9wJNHLRpGkj1ijxX6Ifg3Wtz/Lr4R6lCGdiUbStWSgqS3FcpaoDDoft5Wxn1EqVG5gR3iXL+Z9EKHFTYvKM9vinnNvIB7FVu/FJnt2rrDQm5LtJI8WilBNu7zuvfzQOG+O7ua9ywUXZd6qPdaEFBlUui6K6ievdsDW5c71W2lP3zeS/WMZYfqci2iQTpkblVrHDh6cK4KrJpjCuIYvJgHQH1Xb+8naMo8lez36gB8loxQyzneVcLgFlvvhRsoxFZ/Y6m8IMTRfExs080rlmQngGEsfs+smA41g0iKoKOClS0bNksxmyNpkL7xgIjjt9XTn/M4K0t9PnQcuoprZnTl2SKke1TlZBgSX6hcVoNUOLefkAd05xYHQ1aLvUKu1XjV9pG8wPahAtYHVN7NAyGhq8vNundB4nsoFOkkwYBuPL+iJtxohZ+VRLDeBw3oSWrRUU46aTOKGhTeA6KzoLRr8QbK9lLaIRhZOmuZPJCxltOtSM8XgMYrUuHHsMYzzvIrN5JPMAcoSFuwLMrD+9P5X9b6ubytEB8CWRTzFziJUSP+aFEUiXm4Zl9RtdpO8A77xZyEyIRvfSxNxgdXYZp4z0qHGOthzNrtw== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 31:r1n2T7XCQZ/bQpvG/aArlUaIdHZONlnY7reLylsowfwkIkiO8ARCOTvZ2bbpEQ8LuqnjeT9nDnMVuljybyLsJ3on7bLknv+nGaXSWB5GA3R6v32Yi2hTvs9DTPqx0aI71cfMWqd+qrJxHpRhIuRxlDT/ZseejWHoptTfrlkzJXw0Ti76Zlc4hfMDOlERWBzPPZH1Yi6USwJa5pvvEMvnow==; 20:aK/DdaKblKIiIsEHWa983QC5kYtAvrbdF3W5Yoqql6BZKM6F7U8mzMDmvx2v/sAx2J+hxcbZcis9hymMi0/CEawLA7GQIHkq4jiCFhGy0dvt0VHCSucs1PE5/LnFj2aK8PlGHHVFog2fQVm+yQPd9QbsBG9a33BrCSslBWOCNfL0g6RO5rMGg0Z7umSDif/K+TT63RLMwSuCTkJ/Z/4whOyv5MdkqaQpQM00Gzb2ZmPHuttW22jICDmAtkPe4D7ZKmG61oWdODAZDOfFSQFQXnhIdG+42BnzxDCULkG6yTMX0zZK9bWbOTqGgOztFLGArKxacyn2a7LO5st6iZlRTdpcqOJ3e5Mq2id5moYukc67yEaAfd9J7v/1ps+dZaPxIrUnD3rzD30q808U2BR2pFfE9QSZTIAzAHuzPSpeNQkbub5wc1cf5YUAGO1FZ3NhuF31RuIUsUtftGBs/xBzd6trvws8aI0egzRXY0KJhUPFkKscs1vPiEuEl2YhZ4H8UBt7S2u77dqbFNav38o5s3CRVmweV3Q2+Hd0jg/QN4TcBR6sGS6yQFfs8FvuZZ+WMY6L+FrpDpuIQdsREETquJm+SZeYdijNkxthKasvPMo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0701MB1720; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 4:wIVl98oBrjtwef2hwzYMn+Lk2rWQn4XGhIQFdMUXCdLFoSVVKlaGqpFEv5pKAwNk+7tp6dbv1uG9/I1Kql4eC0DPDFLGzdFLeAqhfDJ+X/lX81cdzcZjXNmGtCb+lNUfAXcvdYs6iEYJGa6dZguYZ+61U+5m7Wf7EYd3azQtaV6KUIF+S2HkttG2OElssW8Ndi9uwzXLaE3nQTS33u+HkiRJDOco6F6Ugtr197MSfK2iQOpRzYrOXRtyccAcYhWIOIjW/HfrVAv/yIuo80M276HrkTds4WcMzd85t2jAwIU+4ewPT+pb3gGH1qAuWrVPA2qpvqzBSXuuKvJolPxs4s5kOttAhW9t7lGfp6ubOTMy5sRNwviyQsFCNTdva4wQ0d/DKsw8r+Qv7JY+zhNJCLNWgWk5Mhgcd3JAzp3E7FxnwvC/4SgzHjObpagGFkCX X-Forefront-PRVS: 0993689CD1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(199003)(377424004)(24454002)(377454003)(189002)(66066001)(23726003)(93886004)(50986999)(1076002)(6116002)(3846002)(42186005)(19580395003)(110136002)(83506001)(4001350100001)(54356999)(76176999)(586003)(68736007)(101416001)(47776003)(189998001)(97736004)(7846002)(305945005)(2950100001)(7736002)(105586002)(15395725005)(77096005)(46406003)(2906002)(15975445007)(4326007)(50466002)(33656002)(92566002)(9686002)(8676002)(97756001)(81166006)(81156014)(106356001)(61506002)(7099028)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1720; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0701MB1720; 23:eGN6Y0VGpR5M2DhJ1+JzjrCrU1fFk/EV2qLtsN2?= =?us-ascii?Q?QvPirWjIfa5MoNzufj/XMRwms5B2OqLJggKYu/7nkH4moc7j3LksQc0hjrWG?= =?us-ascii?Q?9tJpYjiC9bLTSA4MjylBEWMZLrhhAZyAH9SY8fQ1ZNiMqBnMrq5uDknxUd01?= =?us-ascii?Q?oO78Jut1z+pG65y6KgdQOD0DYnL5Yec1ygyfLgCeTRyfNnTjo4ttU/68Grpj?= =?us-ascii?Q?7Vf1gO5Wz/nah89Z5g5GH6ppTd7A6YDzzo2L6SggCl76NNPga8PCYqhaIvXB?= =?us-ascii?Q?EtBHW8Z0sbY4sW+YhCjDCVjqZmK1wAUeUEWubvkoUrEZxLffCvCLqfDyMDMh?= =?us-ascii?Q?aPwHRON6QzYnF0VP7WvRTDzYfHOfZMlvEHStaQIAEsLLSmNuN3R6JGsPu7oI?= =?us-ascii?Q?PvrHsEIF4L4bKvI7Ej+Z2Z8WyerG+3keOAXig2GNIe+47kboC83LhNdjeKNz?= =?us-ascii?Q?edxNi7nl8I94qAVZwzzJKvrAvaxGzPKtueHp2lfJx7Hwkvsy00ZEmP0G27fJ?= =?us-ascii?Q?QO9MLKiNEOKRUxIp/QFrJd7X7Q6bupGB9rPniY33jA5OSYNSMNnhbeeVOsqa?= =?us-ascii?Q?Mk/8aZAN91Lx/vgwXlfnQVTuW/Skf4i1e4KIxlD6HbdJpIJotmWRuLj8h6Ed?= =?us-ascii?Q?+AhTZzKUdz2XzFMcbw41SZQL6cqBRN49KcO5S+YQ5jqafDCQInpZgY1O5ydt?= =?us-ascii?Q?61qytjV2cXiZEV5rT+zJHusINaMzw0V6NtnBhcEI32FozdJ1OFE9TSAkDmSD?= =?us-ascii?Q?9SYl1ACheyj3hoM6qr7AHdyoIO/lolN03b2zZ/Phrv5xJteCr1TKhkUsfUcZ?= =?us-ascii?Q?cOo2k+0VjM0v6Pg5jTd7rfLwK0S6Y4ok6zZ28wFaevRPYCrPGyUSj5cH89Py?= =?us-ascii?Q?JE383FPkI62SN424Bgqq9kllSsDrdgFoEsmZTwFPR+mLFVsBz7//5DcmwUCn?= =?us-ascii?Q?ELqCL1w8wacgjM8pKQeD1uoN+HJiNa43A7VYtICBR9CGxyN23XMUgUXI3tfo?= =?us-ascii?Q?nXopgo0c1gFlK/pppQ86Zd/EoMxVTDx69Z1xUDnCcO1Jn3sYDYCFuGiCcGw2?= =?us-ascii?Q?QdmGh1t3XByz/d8PTSD+CQb5HNKNEAlW5btjhLy8ShuQ7++gn5UWXpreYvOU?= =?us-ascii?Q?zLKl5WL6dJ/NIQ+xuOkZerDLH6gEk/mBBSqmJENOykbVHmJiFb3nh24tPpzE?= =?us-ascii?Q?u+7jn1Wo0ZCofW/4xL+ywLH2Am9sX0OgDMaAthxCHqvwrUm4qFjwq0YpakEQ?= =?us-ascii?Q?XNlfsnewqfGYex9nCg8yB4/XBYJ4G501Y1hZE4h7+RlgDinIPwA77AI4Brov?= =?us-ascii?Q?PBQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 6:zJ6Wh4lQmzShKKQ60PV0OvDOnkAHJzPEfkFjKjkEdPcRL4bAYR2xGlohOIwd6v80++n7o2FH7MPrL5NhRqlyeae+fALUIbrFEix1+/DId32ML+CA8Czb/gM2Eha/XfZyILWh/VmMiUovqXcg1QDTbicWBza0mcjO4mYTbquS/nS8r76DRKLGSHCHJSaeAxvkpYe4xKS6zAAK36RrwhKbk5s31lfccs/u5J5lJYc0JCdlw+hbh6NW/8GT5UOfbx6L2/PpEO1c/80/gY2UeWA7pF+dJLYjbJOLyamZmLywfkM=; 5:QhVF/fXn2v3HykyFOqsseE0QczPhmn/oQ14FIuQjs/qCjH8uxGnt5m1co4CgcUosVKe+yMASqo9UA3R6FaDbQwm3zSH+byM5vPvbl07cSaETwP1cr7C+UuGqQ7FC9gMEmVriAscCUUQKo/NuvTcWcw==; 24:SL92kvvXZA6+E0LyFhh2rEpmHqP4EMNeDg7V//Ou2ijxqZ/CtdyJQhPgK8ofyKymFj1M+a0nZ0E722r4tSP37ceWLMAhQ/5YzN9bHLSyN84=; 7:ipKTbwWSTm6Ja79T+2UQkxuPRj4RczupmnBGJ40Ope1mFV0FeAfR69CsgBGG3DMyVX99oV88zc260EvQwva4PAnDlJcjdMRwPShoRJI5V/FT57WE0+B6Ra1hVwF0R4BvXZCyc5YxtZTHdOnAkjwhgtBGdajydvWk0FZOAvgXdliI7VQeSFFUafG89KXQYx6cU7OItG6NVo/9ntWfmufJXpQX2g+8L6DIb7yc47PZf0pomrbQAuU+6mnX6/a+TI3N SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2016 12:46:01.2082 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1720 Subject: Re: [dpdk-dev] [PATCH] mbuf: make rearm_data address naturally aligned 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: Mon, 04 Jul 2016 12:46:05 -0000 On Mon, May 23, 2016 at 01:19:46PM +0200, Olivier Matz wrote: > Hi, > > On 05/19/2016 05:50 PM, Thomas Monjalon wrote: > > 2016-05-19 19:05, Jerin Jacob: > >> On Thu, May 19, 2016 at 12:18:57PM +0000, Ananyev, Konstantin wrote: > >>>> On Thu, May 19, 2016 at 12:20:16AM +0530, Jerin Jacob wrote: > >>>>> On Wed, May 18, 2016 at 05:43:00PM +0100, Bruce Richardson wrote: > >>>>>> On Wed, May 18, 2016 at 07:27:43PM +0530, Jerin Jacob wrote: > >>> I wonder does anyone really use mbuf port field? > >>> My though was - could we to drop it completely? > >>> Actually, after discussing it with Bruce offline, an interesting idea came out: > >>> if we'll drop port and make mbuf_prefree() to reset nb_segs=1, then > >>> we can reduce RX rearm_data to 4B. So with that layout: > >>> > >>> struct rte_mbuf { > >>> > >>> MARKER cacheline0; > >>> > >>> void *buf_addr; > >>> phys_addr_t buf_physaddr; > >>> uint16_t buf_len; > >>> uint8_t nb_segs; > >>> uint8_t reserved_1byte; /* former port */ > >>> > >>> MARKER32 rearm_data; > >>> uint16_t data_off; > >>> uint16_t refcnt; > >>> > >>> uint64_t ol_flags; > >>> ... > >>> > >>> We can keep buf_len at its place and avoid 2B gap, while making rearm_data > >>> 4B long and 4B aligned. > >> > >> Couple of comments, > >> - IMO, It is good if nb_segs can move under rearm_data, as some > >> drivers(not in ixgbe may be) can write nb_segs in one shot also > >> in segmented rx handler case > >> - I think, it makes sense to keep port in mbuf so that application > >> can make use of it(Not sure what real application developers think of > >> this) > > > > I agree we could try to remove the port id from mbuf. > > These mbuf data are a common base to pass infos between drivers and apps. > > If you need to store some data which are read and write from the app only, > > you can have use the private zone (see rte_pktmbuf_priv_size). > > At the first read, I was in favor of keeping the port_id in the > mbuf. But after checking the examples and applications, I'm not > opposed to remove it. Indeed, this information could go in an > application-specific part or it could be an additional function > parameter in the application processing function. > > The same question could be raised for nb_seg: it seems this info > is not used a lot, and having a 8 bits value here also prevents from > having long chains (ex: for socket buffer in a tcp stack). > > Just an idea thrown in the air: if these 2 fields are removed, it > brings some room for the m->next field to go in the first cache line. > This was mentioned several times (at least [1]). > > [1] http://dpdk.org/ml/archives/dev/2015-June/019182.html Can we come to some consensus on this for this release. The original problem was mbuf->rearm_data not being natually aligned and the assosiated performacnce issues with ARM architecture for non naturally aligned access. I believe that is fixing in this patch without any performance degradation on IA. I believe that is a good progress. Can we make further mbuff improvements as a additional problem to solve. Thoughts ? Jerin