From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0100.outbound.protection.outlook.com [157.56.111.100]) by dpdk.org (Postfix) with ESMTP id 057758D3A for ; Fri, 18 Dec 2015 07:35:10 +0100 (CET) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@caviumnetworks.com; Received: from localhost.localdomain (122.167.182.162) by BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 18 Dec 2015 06:35:06 +0000 Date: Fri, 18 Dec 2015 12:04:48 +0530 From: Jerin Jacob To: Yuanhan Liu Message-ID: <20151218063444.GA8572@localhost.localdomain> References: <2241331.HNmyzf8foi@xps13> <2979402.yeVYlcCDUH@xps13> <20151218053053.GL29571@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20151218053053.GL29571@yliu-dev.sh.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [122.167.182.162] X-ClientProxiedBy: MAXPR01CA0066.INDPRD01.PROD.OUTLOOK.COM (25.164.146.166) To BN3PR0701MB1720.namprd07.prod.outlook.com (25.163.39.19) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 2:Ah8TQk6aokguT462a2yiWryNl1Vejjlv90fp3a10ySvyEgItg8eVbIoAooJ9iBwMURBA7kyao1MTmDF7Km4ztO8RfGoW3FOvM0FnnsRXqozNJdTidXTkgiO3romK9dF2kiw+jM/SooIzv4NNomkl7Q==; 3:R5mZxcbd3H+7KEmfI0YBxPLPeGKA/OGO+m8b90toCfQ7v93BMRNEgrO5mdthcbFcom94/iaFB15HhAcsKbosV+FukFHU+2YGOyPoV/J1OkJcNaWO8wYHBzuGQeoi4Ddm; 25:Kuh8SoxbBEthRpSI5pEmFqy4d2uMHKpGr/Sj+/2kS0H6fVJ3KR5JZnLGinqicN2jXEJsoqdHJoeQkTX/RvzoB9Nvud4YswLBu150NFEyYZsxmb5tBnrn5yAMuPBkr2sNr6x/F5bXt4qmkJZpRaOIQDYk9diUiaYpW9WXlDVDcS9rN+lroJ7cJHKXarN1eVLOX+fucaEtMHP89UHXfYzwk+pqGTiwT6CS+iDLaeiXKhONCNUlKnNHcI5lXs1hdeqJxiQkcs6e6iBny9T0POKYUQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1720; X-LD-Processed: 711e4ccf-2e9b-4bcf-a551-4094005b6194,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 20:D7KxAe8P5E1it5a2e0wt9VK1HXXtC1064RBNrUAx4lFfZew6nMRMPDLcUW2hugQGzwjONfb7+eNC0HFf3mDSbcuALwhIiUzItgIHMSSgiALmHnlGx+Nb0hUK+FlGDWeSJRSK/MQGbxhp+PDXk64UM1bbhXwXQ2SgK0FTlJHw40/h/ggEatjifJS+jgOt9R4w4+veUfrA2H9BIfpUls8XCTf4vrVA8zVSbEGpaBNgC73ugIb82Ez4+21lL7plfCw6JK4gmuuClejiXJqkkqJaPpb1lR3Qq61qlxjopoTCWz/RTW+cqvGHGmnMeOXOLaj3SmL3zRJLtXHotWU2syKwH72uGL8uzO3SMxt92FhiZbPxl1IlvjvKv+uB/gf6PnZtMqf081VAr/gDXswLB3NjtrHUWPAiyubvaCz/6uir1k7tuTtVreOhzighK6/1dT5ZxDcYPbJ7IIdjWTxTKAI3IKD/JXZRS4g5QCQaUKzJkZqyNltKNUTLyY3TG+Un0dZMvaIpOzYFiqiXg4inmcxrxUF7LezIf6iIE69ZX/XZSWoypRKuRS5CSTbTJml2RQ3tRhdgqgzRQ64IDiYBLyCSEBBYl+El0erxBA2rE3K5bfk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0701MB1720; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 4:FBvaMIeNrFlZ+r9/kVg4lVhiTwekqXe31MPAetG7wyb73/1nOjeuyKQPOp3vIk8IwvBVObOIWk+af7u95CHEVaEaSpcUHZn79A2B6rfopSLjymLd1Z8mIUyXD3MBgXcceTH0mwU/Nc1mrPw+0lTPp8NKKrgKh8c7QK/qWneWxSd7C0P7tLrfqzcRmy/lxM6/vC3eCYTOy4tiSJ/NuDaWQOrmHWLB8yN6R7+5sZAuy/CyBI7bfoedYa7pyVOqMSiYVac33EvAa02gpuEGD9B2q5HwmOzvL+MwGf4n4BVFg6GAc11wXH31Ne94WC61qwIJUW6Sk/ogP+7bnlFbfmilKNy/FEX8HohHvAVPiwZX8X0SCkiubroAfHdU3arVrPVv X-Forefront-PRVS: 07943272E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(6009001)(24454002)(199003)(189002)(5004730100002)(83506001)(97736004)(42186005)(76176999)(50986999)(92566002)(77096005)(54356999)(105586002)(106356001)(87976001)(61506002)(4001350100001)(122386002)(66066001)(46406003)(81156007)(2950100001)(40100003)(33656002)(47776003)(101416001)(1076002)(50466002)(97756001)(93886004)(5001960100002)(110136002)(189998001)(23726003)(586003)(86362001)(5008740100001)(3846002)(1096002)(6116002)(7099028); 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: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0701MB1720; 23:8iLOqXAUTojopvRYGgvv+oFjVOc665KaYcMhJKi?= =?us-ascii?Q?SUyUUKVkUOl1FSMd2kwQ1IHd0pcmvSdF1QdbwoFZ7qXJm7ePTT69W/ZI/j6L?= =?us-ascii?Q?aRC7YXONCP+oUGGIP2Kwmio5KSfeSdIqrN4HdwIHjOF7O9lZWNRYKh8qYSYv?= =?us-ascii?Q?ch/wtqTlnqzJgbT6rE5dGOQu4qKfYjk1fTHjp77dBu32OI+cmpAOHq+Au4Nm?= =?us-ascii?Q?595jHojXQXWoJ8hUR4LWIKtrTMYKbNfg5KzCKvTYiOrNbYfoQzyJtzCH51qi?= =?us-ascii?Q?wMKzBOMtIl3Vg2i8VGlRnMzz7X7ayOdDVjCrWy6NtKYLQogOW6WFskT47IoL?= =?us-ascii?Q?uMUboKCWcfUs7cQSxv4stXqyEmnzufz3V4odhICjVgpfywjOH2sYKrU/Zh8A?= =?us-ascii?Q?QbKatLT5PS8h6HY2hRch9gYVj2DTdcRiHE7HKpMH99crUH0L1bcUM2kfsuUU?= =?us-ascii?Q?OKUJoqh0HO/jed6cxTC3kG2TCEG7fBm/m7to1AFqaJjwT8rhL/fabEZTr4qA?= =?us-ascii?Q?ZvWAi8izXfVRT6KWSKIPDQ+h3Jxre4oy7zqmAj3uzTYUmIb4GJ39pDhQlVtP?= =?us-ascii?Q?bg9yd7HhuoTYCn6ogjH0tcj/CTGpxCHjMKz0iOtpTZIQ6pZOQuAJ5rtaIRma?= =?us-ascii?Q?8gXVtGJMGlPprJKZ7/mvvFqZzBu/6cyHPk/95agZqy9TSyKfiqGhBaI9eZh9?= =?us-ascii?Q?EuTGMcVup/r2enxzNW/rd21cuunOmVPbemniQVbby6M1MfKgdf12lIBpVJEL?= =?us-ascii?Q?rHhpvKqKa+Tdxqegh7pAja9LzaBMINfiIEDk0tdi0MBYG2E4IWxvMILZzDLL?= =?us-ascii?Q?XkzOGn/j9tJUvJOnZcqfD1Mdeic0ChlhjEMqUeQiCM0I1ulRkvw9UOHLLr2N?= =?us-ascii?Q?k1+pi5VCumqbYmM8+oPK17IyXadGHuUzeCgL1THDeBwGSLxZOeC6LzvOSbhl?= =?us-ascii?Q?F4JC5ZW6EaplAAHHQZVcbRHiBFHPKFLOpY28c6NJSF20qXLKgzT/AjQhYuTy?= =?us-ascii?Q?yIX7gAxhUIJ5tp5wPLa64j+u6d0Sblgk4pVGmv8dQo437A6Kh/hRHEAMzbo2?= =?us-ascii?Q?qdqZNnrX5Pns4RLAoMKdF9thtzpGqHzmWsRpI7YJaIxXRVbWXqNYXG5+gDF2?= =?us-ascii?Q?yjZ8xxmZ8Y/I=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 5:7UHsnIL9M7Az7q3SU5swdWmxhYkBimtuSmdJS6svGIEr98Y8Qvu5Y9bhV8z9gqNcFQh6tBNihskvF3T/P1MX6ZA1laB/4srYHR5mYktrAOQ72ENUSYF4PwW5CP4y1LCtvAQrB5lxim94JxFm1Dgxaw==; 24:jWLTzpp6VV0ZE1c0USzLksieXUTrcnaQd3kmMHlsgjri7o6eHG82ECWUPBcxZ8FbAMfzmEMSgfSGsovGxMw3195mV7xAq3DwGu7kQDYLqX4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 06:35:06.2376 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1720 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal: map io resources for non x86 architectures 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: Fri, 18 Dec 2015 06:35:10 -0000 On Fri, Dec 18, 2015 at 01:30:53PM +0800, Yuanhan Liu wrote: > On Thu, Dec 17, 2015 at 04:52:00PM +0530, Santosh Shukla wrote: > > >> >> IMO, it is worth keeping one special device file who could work across > > >> >> archs like arm/arm64/powerpc and others, who could map iopci bar to > > >> >> dpdk user-space. also this approach has no kernel version dependency > > >> >> too. BTW; I did mentioned in second approach in to add /dev/ioport > > >> >> interface in drivers/char/mem.c which could read more than byte in one > > >> >> single operation, but that has kernel dependency. However that > > >> >> approach too is arch agnostic. > > >> > > > >> > Your first approach use an out-of-tree kernel module (igb_uio), so we cannot > > >> > really say there is no kernel dependency. > > >> > > >> Agree but I mentioned kernel __version__ dependency. > > > > > > Yes you did. > > > One of the main issue with out-of-tree kernel modules is the version > > > dependency. Probably that igb_uio from DPDK 2.3 will not compile with > > > the kernel 5.0. > > > > > > > don't know kernel 5.0 feature list so I guess your may be right. is > > uio obsoleted for 5.0 kernel? > > Nope, Thomas meant to say that we should keep the old DPDK will work > with newer kernel, not just the newest DPDK work on newest linux kernel > only. The out-of-tree kernel makes no garantee on that. > > > >> > We should try to remove the need for any out-of-tree kernel module. > > >> > That's why the Linux upstream approach is a better solution. > > >> > > >> IIUC, your suggesting archs like arm/arm64 to support io_mappe_io in > > >> pci_mmap_page_range()? > > > > > > I don't know what is the best solution in the kernel. > > > First we need to be sure that there is absolutely no solution without > > > kernel changes. > > > > I guess we have done enough evaluation / investigation that suggest - > > so to map iopci region to userspace in arch agnostic-way - > > > > # either we need to modify kernel > > - Make sure all the non-x86 arch to support mapping for > > iopci region (i.e. pci_mmap_page_range). I don;t think its a correct > > approach though. > > or > > - include /dev/ioport char-mem device file who could do > > more than byte operation, Note that this implementation does not exist > > in kernel. I could send an RFC to lkml. > > Maybe you could propose the two to lkml, to get some feedbacks from > those kernel/ARM gurus? Please cc me if you do so. IMO, We need to support DPDK-ARM for the old kernels also. If there is no means to expose iomap region to userspace in the existing kernel then we add that support through out-of-tree driver like igb_uio and when make become part of the kernel then we can turn off of the out-of-tree driver based on the kernel major and minor version numbers. Jerin > > --yliu > > > > OR keep device file in user space (current approach) > > Right now Virtio-for-arm patches are blocked on this, let me know if > > someone has better approach/thought in mind. > > > > Thanks. > > > > > Then we can try a pci_mmap solution or, as you suggest, an interface in > > > drivers/char/mem.c > > >