From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 89FA05A0A for ; Wed, 23 Dec 2015 06:13:18 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP; 22 Dec 2015 21:13:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,467,1444719600"; d="scan'208";a="18004689" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga004.fm.intel.com with ESMTP; 22 Dec 2015 21:13:17 -0800 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 22 Dec 2015 21:13:16 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 22 Dec 2015 21:13:16 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.190]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.151]) with mapi id 14.03.0248.002; Wed, 23 Dec 2015 13:13:14 +0800 From: "Xie, Huawei" To: Yuanhan Liu , Peter Xu , Thomas Monjalon Thread-Topic: [dpdk-dev] [Question] How pmd virtio works without UIO? Thread-Index: AdE9QJ8nl8VXEhglRhmhlN1f6b8L3Q== Date: Wed, 23 Dec 2015 05:13:13 +0000 Message-ID: References: <20151222035041.GA7532@pxdev.xzpeter.org> <20151222070029.GO18863@yliu-dev.sh.intel.com> <20151222082338.GG7532@pxdev.xzpeter.org> <20151222083246.GT18863@yliu-dev.sh.intel.com> <20151222095641.GH7532@pxdev.xzpeter.org> <20151223020135.GU18863@yliu-dev.sh.intel.com> <20151223024157.GE1694@pxdev.xzpeter.org> <20151223025858.GX18863@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DPDK Dev Subject: Re: [dpdk-dev] [Question] How pmd virtio works without 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: Wed, 23 Dec 2015 05:13:19 -0000 On 12/23/2015 10:57 AM, Yuanhan Liu wrote:=0A= > On Wed, Dec 23, 2015 at 10:41:57AM +0800, Peter Xu wrote:=0A= >> On Wed, Dec 23, 2015 at 10:01:35AM +0800, Yuanhan Liu wrote:=0A= >>> On Tue, Dec 22, 2015 at 05:56:41PM +0800, Peter Xu wrote:=0A= >>>> On Tue, Dec 22, 2015 at 04:32:46PM +0800, Yuanhan Liu wrote:=0A= >>>>> Actually, you are right. I mentioned in the last email that this is= =0A= >>>>> for configuration part. To answer your question in this email, you=0A= >>>>> will not be able to go that further (say initiating virtio pmd) if=0A= >>>>> you don't unbind the origin virtio-net driver, and bind it to igb_uio= =0A= >>>>> (or something similar).=0A= >>>>>=0A= >>>>> The start point is from rte_eal_pci_scan, where the sub-function=0A= >>>>> pci_san_one just initates a DPDK bond driver.=0A= >>>> I am not sure whether I do understand your meaning correctly=0A= >>>> (regarding "you willl not be able to go that furture"): The problem=0A= >>>> is that, we _can_ run testpmd without unbinding the ports and bind=0A= >>>> to UIO or something. What we need to do is boot the guest, reserve=0A= >>>> huge pages, and run testpmd (keeping its kernel driver as=0A= >>>> "virtio-pci"). In pci_scan_one():=0A= >>>>=0A= >>>> if (!ret) {=0A= >>>> if (!strcmp(driver, "vfio-pci"))=0A= >>>> dev->kdrv =3D RTE_KDRV_VFIO;=0A= >>>> else if (!strcmp(driver, "igb_uio"))=0A= >>>> dev->kdrv =3D RTE_KDRV_IGB_UIO;=0A= >>>> else if (!strcmp(driver, "uio_pci_generic"))=0A= >>>> dev->kdrv =3D RTE_KDRV_UIO_GENERIC;=0A= >>>> else=0A= >>>> dev->kdrv =3D RTE_KDRV_UNKNOWN;=0A= >>>> } else=0A= >>>> dev->kdrv =3D RTE_KDRV_UNKNOWN;=0A= >>>>=0A= >>>> I think it should be going to RTE_KDRV_UNKNOWN=0A= >>>> (driver=3D=3D"virtio-pci") here.=0A= >>> Sorry, I simply overlook that. I was thinking it will quit here for=0A= >>> the RTE_KDRV_UNKNOWN case.=0A= >>>=0A= >>>> I tried to run IO and it could work,=0A= >>>> but I am not sure whether it is safe, and how.=0A= >>> I also did a quick test then, however, with the virtio 1.0 patchset=0A= >>> I sent before, which sets the RTE_PCI_DRV_NEED_MAPPING, resulting to=0A= >>> pci_map_device() failure and virtio pmd is not initiated at all.=0A= >> Then, will the patch work with ioport way to access virtio devices?=0A= > Yes.=0A= >=0A= >>>> Also, I am not sure whether I need to (at least) unbind the=0A= >>>> virtio-pci driver, so that there should have no kernel driver=0A= >>>> running for the virtio device before DPDK using it.=0A= >>> Why not? That's what the DPDK document asked to do=0A= >>> (http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html):=0A= >>>=0A= >>> 3.6. Binding and Unbinding Network Ports to/from the Kernel Modules= =0A= >>> =0A= >>> As of release 1.4, DPDK applications no longer automatically unbind= =0A= >>> all supported network ports from the kernel driver in use. Instead,= =0A= >>> all ports that are to be used by an DPDK application must be bound= =0A= >>> to the uio_pci_generic, igb_uio or vfio-pci module before the=0A= >>> application is run. Any network ports under Linux* control will be= =0A= >>> ignored by the DPDK poll-mode drivers and cannot be used by the=0A= >>> application.=0A= >> This seems obsolete? since it's not covering ioport.=0A= > I don't think so. Above is for how to run DPDK applications. ioport=0A= > is just a (optional) way to access PCI resource in a specific PMD.=0A= >=0A= > And, above speicification avoids your concerns, that two drivers try=0A= > to manipulate same device concurrently, doesn't it?=0A= >=0A= > And, it is saying "any network ports under Linux* control will be=0A= > ignored by the DPDK poll-mode drivers and cannot be used by the=0A= > application", so that the case you were saying that virtio pmd=0A= > continues to work without the bind looks like a bug to me.=0A= >=0A= > Can anyone confirm that?=0A= =0A= That document isn't accurate. virtio doesn't require binding to UIO=0A= driver if it uses PORT IO. The PORT IO commit said it is because UIO=0A= isn't secure, but avoid using uio doesn't bring more security as virtio=0A= PMD still could ask device to DMA into any memory.=0A= The thing we at least we might do is fail in virtio_resource_init if=0A= kernel driver is still manipulating this device. This saves the effort=0A= users use blacklist option and avoids the driver conflict.=0A= =0A= >=0A= > --yliu=0A= >=0A= =0A=