From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F0AEDDE3 for ; Thu, 17 Dec 2015 10:57:04 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP; 17 Dec 2015 01:57:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,440,1444719600"; d="scan'208";a="875566674" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2015 01:56:39 -0800 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.96]) by IRSMSX154.ger.corp.intel.com ([169.254.12.98]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 09:52:50 +0000 From: "Burakov, Anatoly" To: Thomas Monjalon Thread-Topic: [dpdk-dev] VFIO no-iommu Thread-Index: AQHRNDFBwI3804ANPk+mxhFdQwV0QJ7GWa0AgAAN+YCABa0GgIAANSMAgAC7bgCAAAmbgIAAQC9AgACBEuCAAHdYgIAAsN6A Date: Thu, 17 Dec 2015 09:52:49 +0000 Message-ID: References: <60420822.AbcfvjLZCk@xps13> <17700135.Qc9aIsHGGP@xps13> In-Reply-To: <17700135.Qc9aIsHGGP@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] VFIO no-iommu 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, 17 Dec 2015 09:57:05 -0000 Hi Thomas, > > Hi Thomas, > > > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > > > So it works. Is it acceptable? Useful? Sufficiently complete? > > > > Does it imply deprecating the uio interface? I believe the > > > > feature that started this discussion was support for MSI/X > > > > interrupts so that VFs can support some kind of interrupt (uio > > > > only supports INTx since it doesn't allow DMA). Implementing that > > > > would be the ultimate test of whether this provides dpdk with not > > > > only a more consistent interface, but the feature dpdk wants > > > > that's missing in uio. Thanks, > > > > Ferruh has done a great job so far testing Alex's patch, very few chang= es > from DPDK side seem to be required as far as existing functionality goes = (not > sure about VF interrupts mentioned by Alex). However, one thing that > concerns me is usability. While it is true that no-IOMMU mode in VFIO wou= ld > mean uio interfaces could be deprecated in time, the no-iommu mode is way > more hassle than using igb_uio/uio_pci_generic because it will require a > kernel recompile as opposed to simply compiling and insmod'ding an out-of= - > tree driver. So, in essence, if you don't want an IOMMU, it's becoming th= at > much harder to use DPDK. Would that be something DPDK is willing to live > with in the absence of uio interfaces? >=20 > Excuse me if I missed something obvious. > Why a kernel compilation is needed? Well, not really full kernel compilation, but in the default configuration,= VFIO driver would not support NOIOMMU mode. I.e. it's not compiled by defa= ult. Support for no-iommu should be enabled in kernel config and compiled i= n. So, whoever is going to use DPDK with VFIO-no-iommu will have to downloa= d kernel tree and recompile the VFIO module and install it. That's obviousl= y way more hassle than simply compiling an out-of-tree driver that's alread= y included and works with an out-of-the-box kernel. Thanks, Anatoly