From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0098.outbound.protection.outlook.com [207.46.100.98]) by dpdk.org (Postfix) with ESMTP id 5762B6C96 for ; Thu, 12 May 2016 12:31:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2XkQ6PaM86mO6GABtT2iohFHRGH750tu3EOCRpMN9/o=; b=E3Y/CS9ub/P71As7WyDW0BfxDTcHs0kk0IPaSlT0lpNBZzttfroMu1cYbYVdae3aNHWGz/ZnWuqQ4SdOsZsoegkDoL+C0XhMnvZpb7ZiD0f+Xh55JKmonaIdHNUYKCRdQvzs/EeVtqQy4dd/GgNBtqwLjtwXoo7zHvZB88v9lgA= Authentication-Results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=caviumnetworks.com; Received: from santosh-Latitude-E5530-non-vPro (111.93.218.67) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 12 May 2016 10:31:32 +0000 Date: Thu, 12 May 2016 16:01:05 +0530 From: Santosh Shukla To: Jianbo Liu CC: Stephen Hemminger , Jerin Jacob , Hemant Agrawal , , Thomas Monjalon Message-ID: <20160512103103.GA16360@santosh-Latitude-E5530-non-vPro> References: <20160511082259.42905f98@xeon-e3> <20160511170215.GA1637@localhost.localdomain> <20160511112559.69dcff13@xeon-e3> <20160512031642.GA5855@santosh-Latitude-E5530-non-vPro> <20160512050638.GA7301@santosh-Latitude-E5530-non-vPro> <20160512083342.GA12841@santosh-Latitude-E5530-non-vPro> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: PN1PR01CA0050.INDPRD01.PROD.OUTLOOK.COM (10.164.136.150) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: 2e988262-4f87-4d58-a3df-08d37a509866 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:fNv71E77BduDRZ0mdvk7bhKTo+/ZtwPVg28GRRQU1XsCbbPNLJ0hIVn8suyM6Nxont7tIvNuTZmDJE8ac198/4mt+pC46+Do9IvWWcgxel7FaRV2JFdUGHZqv2yDXvhwwKQEGL4fzejMwKD9a/gXdt28f8SvdHhgsC2CEvQD3zZFzoTUxg8e9PWpHZMZhAcb; 3:ZvbY2aXeEsjV4a9Mrv/DYo9TbJuTb4+0RKonHMA7n1XIiImwLOssv5hbOu4R7zfCFublJ8sJZemAPqRcCJera3jdDLhMwBlPsuaIBJKioDTjihtXhU/bkMoJypqw0mAc X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 25:qV8daFNlbxD9vxtsCWsButpfEjrAMCP7tbptr8NXyE9HPrL8qFl7blc7afa3Mc7ugb/xMnryjLV0atdOH8lYiupwIWSc4tmOqfjnQdrNxeJvABy8iqlSBkdMEIdmjyyrhLv8WNI4nzTiA8eN6iUpshCO8fUvQAr1l2P16XjyTDWN99wQ2OkqzmCATnJeuHtmpwArdTIxx6QikViwvvBnlYMmXuRLrnXy3P8Y/GOkR6XrjQidqEA/uBxcSwDenqJ+trp0on0FXHMNRgWX/cSi6F5Ih1Ujhmj2d5RJF9L92+jcMtLwTEwmHmx8bc8hSl4qtPkuxmDyqObqrnEu91/SQS7gMDBefv30jyotmVDG37DkAYoYy5OCToLHCv0rLeXoN5HW22McShokV6uAmqCuuPEFAm+Ook9xJlI+rO0PFmaIz+JaFi1QwvVsUFLZBqMdhqVvUhF1zkyuhYnhLVWcCRVJoZ5wPM5q2EgDRo4F5fv5Dbo2gHU/Is3xtw0mXbh2Rc5hkupgT20ppsN21LqRAIa/vImRNWTLbBPtUaGruBrTAo9cfeOuzOYn2U0T/OG0bnsm6OTRgZqWamyMzmY5kGdLOA+Lr+ark3ISkrLItGNYIxivorz7eyY0avI2i3rILmcWopXzhZ/uWM3g1If6vD5SqHbZ1/g9YtTMIXI9Q1cNkEVogajRRHOaDLUHsmAGuqAFz4A3vtB/2HVl9lw6mOF+yech22ioPFzSpsuzQn3jlnu6oLOt14AWINFACn4ySXfV8u3aOvYQxFVEprr6rvawx1YK9ZA60CxfInK8PCHSGyqwIDTb2/u65I7PPQmFkKYpMuKDHZTJlpnTuhgvPA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:uFlnwFQdMiQtXoGXI5IcchoJI/QJHdPpYI/kKj0tCfLP4FlwjELAAiqzuAiD53HcZamVC0oCPJqhKtUyvjkrWUbsUCWb+Wc3gfsVcjUPJfhTiEpfFozH/8DsMc2MUpqsI1wT6YVk28Y+NNuP53zsVo6gepryukYDYFwIlXNnUU+pAVp/fYcBRSN7Q5f7Xiw4NmjlJiTPyfplUKengCAYYHwNbuts7Qo9zMsCsTnYxm4PdijSelPBz89LYFD9+0r4ZM4turzLcfNLMBFTXpMxecpbHJsQbaNir+tOTVXrvDplNRnigQu+/5l4x+wXbUMxktetWEtskO9dAhpuFY8+NMI3h19GPAXzcb/npRXYeTtcqYY3+6OqjA+UeO6MbQo4vovAuQi6M09ypSGQUq7WGxyWxa5eA48ovoGIK9wvIugCU7yHtay15iKAN/MU2DbXZPnM0LWRcfEAoUDV4ZKYUGE+gR9E+fb8ZG1dxDvMStfRcjAq921KgQtfna21+co2hN1pd0F8qMxZIaQUbzi34WNpckpQBsV1cLmJBFV2i3Yo61ZGqCE+aKhIvY+pkkAyic0FfojuuFZa0LfoJhHm6Wf5BRsI+MyfzWFrsR+j8CI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:xwVBVOaZw+dupvoA5ZOiFl8y5U+cHpx8njt8gT3YWuPIeSJy0M//euN8e+8qUrcwYs0YGW/e72BIJVkdcEqZrb1oWgcq3grmnuE3f/rnEi3eF/ZemAbX1LFCIMMQNV3QM0sXln5uRr9+2C8e9fQQ+0v7pY1QW4EKMC0WRRb5hbjOTQCkVXGQQnYLDTRi2VNfxOXp/XdZrT4Nnd/8S7s+ih3O5qIaD3PElBTDZj5GA2yOT7pHEbrHNb21laOMxqsypfrp1EqXiEj/I64bx6szHFC6QcC+L9uEIF3Xs0YbgWkA7jXA5ZJG8noCabmpTbdVKcIsBQ72ghsQNwBMWorDfVutZczefpAWAGLLR3AkIQY4garCDrU0imBybWFBbgZr X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(24454002)(50466002)(4326007)(586003)(5008740100001)(2906002)(5009440100003)(15975445007)(46406003)(15395725005)(97756001)(33656002)(77096005)(66066001)(2950100001)(93886004)(23726003)(6116002)(1076002)(33716001)(3846002)(4001350100001)(47776003)(9686002)(76176999)(50986999)(19580395003)(19580405001)(54356999)(81166006)(189998001)(5004730100002)(92566002)(83506001)(42186005)(110136002)(7099028)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:santosh-Latitude-E5530-non-vPro; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:H7hZ8HO7mMBT1SgwdMCZ89gzmxBgUPdTvDllxei?= =?us-ascii?Q?ru18ShoBKfg52YQjIPAW3VuSSYQrBv6yfVCxVQZ3niREuiSWrZagZMjL9ha5?= =?us-ascii?Q?sutx2uEkQjyrNwByX3bOtwhoTH9sWTojT/yBos1F7FcS4wc/inIAq5HQolyK?= =?us-ascii?Q?id1cdg8m7YgRtOqe28xIoMRmyGF76pmbYrwMEUCnlJ5NfaIrynECLL9/i+Xb?= =?us-ascii?Q?gxKqr8vwzqvZW8/OKkz91hNQiAuibdbd03zkYWFZfGEXWRuwZhvQFoi1nwj4?= =?us-ascii?Q?hY5IxvBxGVpv1iEXyWNreUVLTM1rn7QhglqKsLrpvgf0y0t/g8IdN+CKC3ib?= =?us-ascii?Q?1uoCeZ9dGXyycNvMtUmsNWUXiPaM4oU1lIu1rBCyabzIaC0wmFZuVu4uX880?= =?us-ascii?Q?uXN0cnXeFNVNpLkYmFomZaZP/wjlz7wS4/3+Ow/6Ypx0Yw4zTKxFALJnFhlL?= =?us-ascii?Q?yMhnyGmH2dDySoMKgHJju94TbDvgIBzKVT4eCUKh8uDIUnGB3ii9Ku+8BCQC?= =?us-ascii?Q?LwKJOWpBnuV5aOHItW9mn5yBrrGpB0ITzyR/YTotP+W1xjC7SFMhEllhGBPH?= =?us-ascii?Q?h8j6ML+p3gYeOuXaSbuH6LxY7Grzz3GzrC+C/sqLbSKd0QXhqs3nUnqJXi00?= =?us-ascii?Q?da4xTJumtgFJt3KGdz6w1OWsO3k75rtSwZeJQdKI9XyEBRmzFGQTgJ/8LL5/?= =?us-ascii?Q?KDGbWqN/jCqPExQJs1K2Wxt4B1hxdkfEZFeROPtOnm6o8SBm/QWSJw0Qqnie?= =?us-ascii?Q?zXm6efkHGEGOZeD6LZp3C1ZhZvFIw6yXLaRGp5CCq2xierOk6NR4U3gIE8T6?= =?us-ascii?Q?L1k0+Vbj5rsCIaReZOilo0RfewiZy+oI1PHspOlbr/zS90tJQfeMat4zBwVl?= =?us-ascii?Q?j6u0qazEGN9MebYIHNFgBe0laCT4NLkX7RFUant9vAwfdFULL7rfAg5fAhp6?= =?us-ascii?Q?9Pr182gY0wdsZ+YSTWBdPQh7UIyODsjltiPkuO+XafQgWEdM3iPb7cyKCl+b?= =?us-ascii?Q?/3DW6l535kUeW2QNTPlxAePT7GkJtZGNHAqw/XLUF0SXd4Pxgee4dyKH1LBP?= =?us-ascii?Q?O4rPTsx17CQf3UNKGkGl8I7swNtvn?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 5:kjFeFXONhq3gDVTmvuwAi7Ve6qm27cGpd01juRq79o3jsBrKP2EhuPutMfxqshGY1K5Ws5vaYhip1XYGiaw1axdO40F6alz976xrZLE2O8ZGPwuhoRQrqjohgoFfagmyxK+n6+zdOi8JHCqWHMaBVg==; 24:RtjfU1FIY3rvZ7gw/FKrLctigsgGMuWs3v6rGyIclvAR+aGS2J1ZRgRUUQZSeeusp2xQwpBNgvrgWy42IHSJloKmju+hg0wnexjlDmW5cGE=; 7:aD3hJDgv/zeSHglzvSiUx57+qb3hFMO6anrZs8/73OmPnQ9a1uXEJeDtkd/LqhDLPsBr5FxbK6ZKhkNUGVtsE3uY8ruthhbPdVO1E4ueLdA7H+fnEnexj4uWXsN2N1AnJNRkf2h/8A7GZmDzgfpfhCJUDzCZAJl/ZEvcH6tPob9bgR2GpErUZoCP5lsndOeT SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 10:31:32.4860 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Subject: Re: [dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio 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: Thu, 12 May 2016 10:31:39 -0000 On Thu, May 12, 2016 at 05:52:54PM +0800, Jianbo Liu wrote: > On 12 May 2016 at 16:57, Santosh Shukla > wrote: > > On Thu, May 12, 2016 at 01:54:13PM +0800, Jianbo Liu wrote: > >> On 12 May 2016 at 13:06, Santosh Shukla > >> wrote: > >> > On Thu, May 12, 2016 at 11:42:26AM +0800, Jianbo Liu wrote: > >> >> On 12 May 2016 at 11:17, Santosh Shukla > >> >> wrote: > >> >> > On Thu, May 12, 2016 at 10:01:05AM +0800, Jianbo Liu wrote: > >> >> >> On 12 May 2016 at 02:25, Stephen Hemminger wrote: > >> >> >> > On Wed, 11 May 2016 22:32:16 +0530 > >> >> >> > Jerin Jacob wrote: > >> >> >> > > >> >> >> >> On Wed, May 11, 2016 at 08:22:59AM -0700, Stephen Hemminger wrote: > >> >> >> >> > On Wed, 11 May 2016 19:17:58 +0530 > >> >> >> >> > Hemant Agrawal wrote: > >> >> >> >> > > >> >> >> >> > > IGB_UIO not supported for arm64 arch in kernel so disable. > >> >> >> >> > > > >> >> >> >> > > Signed-off-by: Hemant Agrawal > >> >> >> >> > > Reviewed-by: Santosh Shukla > >> >> >> >> > > >> >> >> >> > Really, I have use IGB_UIO on ARM64 > >> >> >> >> > >> >> >> >> May I know what is the technical use case for igb_uio on arm64 > >> >> >> >> which cannot be addressed through vfio or vfioionommu. > >> >> >> > > >> >> >> > I was running on older kernel which did not support vfioionommu mode. > >> >> >> > >> >> >> As I said, most of DPDK developers are not kernel developers. They may > >> >> >> have their own kernel tree, and couldn't like to upgrade to latest > >> >> >> kernel. > >> >> >> They can choose to use or not use igb_uio when binding the driver. But > >> >> >> blindly disabling it in the base config seems unreasonable. > >> >> > > >> >> > if user keeping his own kernel so they could also keep IGB_UIO=y in their local > >> >> Most likely they don't have local dpdk tree. They write their own > >> >> applications, complie and link to dpdk lib, then done. > >> >> > >> >> > dpdk tree. Why are you imposing user-x custome depedancy on upstream dpdk base > >> >> Customer requiremnts is important. I want they can choose the way they like. > >> >> > >> > > >> > so you choose to keep igb_uio option, provided arch doesn't support? > >> > new user did reported issues with igb_uio for arm64, refer this thread [1], as > >> > well hemanth too faced issues. we want to avoid that. > >> > > >> > If customer maintaing out-of-tree kernel then he can also switch to vfio-way. > >> > isn;t it? > >> > > >> >> > config. Is it not enough for explanation that - Base config ie.. armv8 doesn;t > >> >> > support pci mmap, so igb_uio is n/a. New user wont able to build/run dpdk/arm64 > >> >> > in igb_uio-way, He'll prefer to use upstream stuff. I think, you are not making > >> >> You are wrong, he can build dpdk. If he like to use upstream without > >> >> patching, he can use vfio. > >> > > >> > I disagree, we want to avoid [1] for new user. > >> > > >> >> But you can't ignore the need from old user which is more comfortable > >> >> with older kernel. > >> >> > >> > arm/arm64 dpdk support recently added and I am guessing, most likely customer > >> > using near latest kernel, switching to vfio won't be so difficult. > >> > > >> > Or can you take up responsibility of upstreaming pci mmap patch, then we don't > >> > need this patch. > >> > > >> > [1] http://dpdk.org/ml/archives/dev/2016-January/031313.html > >> > >> Can you read carefully about the guide at > >> http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html? It says to use > >> uio_pci_generic, igb_uio or vfio-pci. > > > > *** applicable and works for x86 only, not for arm64: because pci mmap support > > not present for arm64, in that case we should update the doc. > > > >> Could it be possible that the user in that thread has already read and > >> tried them all and found that he can't enable vifo with his kernel, > >> and igb_uio is the easy way for him and asked for help from community? > >> If so, we have no choice but keeping igb_uio enabled. > > > > By then vfionoiommu support was wip progress in dpdk/linux. but now it merged > > and it works. So no need to retain igb_uio in base config for which to work - > > user need to use mmap patch at linux side. > > We can't decide which kernel user will use. > yes, we can't decide kernel for user but we should be explicit to user on - what works for dpdk/linux out-of-box vs what could work with use of out-of-tree patch/RFC's.. example igb_uio. > > > > Or can you maintain out-of-tree pci mmap patch/ kerne source and make it > > explicit somewhere in dpdk build doc that - if user want igb_uio way then > > use kernel/mmap patch from x location. > > The patch is in the kernel maillist, and user google it. there are feature specific rfc's in plenty in lkml/qemu mailing list, and you suggest- user to hunt for all those information. Is this how we;re officially supporting igb_uio for arm64.. that let user to google? > And isn't funny to ask someone to do something again and again (3 > times) in this thread? > I am asking becasue your in favour of keeping igb_uio for arm64 but not agreeing to streamline (writing a note in dpdk doc for igb_uio for arm64 or pointing to working tree).. so that user don;t need to grep or google for known findings. I find discussion going in circle and nothing will conclude, So given up. > > > >> He use lsmod to show us the modules, most likely he know vifo-pci. > >> > >> Below are the details on modules, hugepages and device binding. > >> root at arm64:~# lsmod > >> Module Size Used by > >> rte_kni 292795 0 > >> igb_uio 4338 0 > >> ixgbe 184456 0