From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id BD6185A9D for ; Wed, 23 Dec 2015 23:21:37 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id l126so161789059wml.1 for ; Wed, 23 Dec 2015 14:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=cEHKtoeZKFV/RzZjQ8ajHIWC1rp4X+X4k9PL1mWDrQI=; b=XbAyDEiYGZsVX1cVdLsHogIQb5bAuygPIJr5VA5O2CH45Qbnh1LIcnfepXBd5dQCJn 7IxkVNVQ8YO1qU+eDmR3ehQsx0q0NmqmrOH1/TOwXlXIno81/DSDftPCRUMB1UKv59Nj A41hlFJi2s1kp7ClnTlzgCrAKtltP3DQgikbuF3AspVJ5r7U1GiH1SWudB3GP78aUwXF qh9sQG9cOVwtWQyV+jisP1cwSlUivSvtFTIX0AFjE6sxITJVzfZBlUQhQakwVSh0lr/V g/u9qQpMIqOAiZwFhHC3YySpx31EaJ7XeuoEl+am/HxwdN6KoJKQll5kCAkyn6sjWnUg UQtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=cEHKtoeZKFV/RzZjQ8ajHIWC1rp4X+X4k9PL1mWDrQI=; b=aJlQ+KN4dqAqOhKntgamokvXsA35jZx8/6LdHQwStdMumY6Jl9A3PbXdbO9dyJaJwB Mtz2CWn9NXfoG6Sbu6BgPHckRtKXPiRhuQHLOnGalSNc9V0sBBzUVsK+Jk9YKTm6r4SS uZSeLoxcYexjezptMYzTSTDlYL5KBcFieACz2giH0OcJMtOf74dnJup8zwjqwn0DEQYM qB9jAiDf12BIotD9mH0uE8+ueohnb0wTu57nUu4egPzCalI7hx7juYJkUaCI5ByFi8hC x91w4T7Xp9uPqnmPr0PCwiUw72d3f8/UOsV6S1h5lN169c9iiZiAL8YR13mOIuNRNh/e tvkw== X-Gm-Message-State: ALoCoQk+gynEmO69wdZLvGAfssovOyk6Z9H2BP+WRidsWnIQtXh5LI0Ytnt07YjkCLTU0neIBCRWyDIazPbwyVlPiecYzr5TnA== X-Received: by 10.194.92.4 with SMTP id ci4mr43036662wjb.175.1450909297530; Wed, 23 Dec 2015 14:21:37 -0800 (PST) Received: from xps13.localnet (APoitiers-658-1-50-6.w86-217.abo.wanadoo.fr. [86.217.129.6]) by smtp.gmail.com with ESMTPSA id i196sm19801223wmf.23.2015.12.23.14.21.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Dec 2015 14:21:36 -0800 (PST) From: Thomas Monjalon To: "Xie, Huawei" Date: Wed, 23 Dec 2015 23:20:03 +0100 Message-ID: <3141123.cIR0F9AJJf@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20151222035041.GA7532@pxdev.xzpeter.org> <20151223025858.GX18863@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org 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 22:21:37 -0000 2015-12-23 05:13, Xie, Huawei: > On 12/23/2015 10:57 AM, Yuanhan Liu wrote: > > On Wed, Dec 23, 2015 at 10:41:57AM +0800, Peter Xu wrote: > >> On Wed, Dec 23, 2015 at 10:01:35AM +0800, Yuanhan Liu wrote: > >>> On Tue, Dec 22, 2015 at 05:56:41PM +0800, Peter Xu wrote: > >>>> On Tue, Dec 22, 2015 at 04:32:46PM +0800, Yuanhan Liu wrote: > >>>>> Actually, you are right. I mentioned in the last email that this is > >>>>> for configuration part. To answer your question in this email, you > >>>>> will not be able to go that further (say initiating virtio pmd) if > >>>>> you don't unbind the origin virtio-net driver, and bind it to igb_uio > >>>>> (or something similar). > >>>>> > >>>>> The start point is from rte_eal_pci_scan, where the sub-function > >>>>> pci_san_one just initates a DPDK bond driver. > >>>> I am not sure whether I do understand your meaning correctly > >>>> (regarding "you willl not be able to go that furture"): The problem > >>>> is that, we _can_ run testpmd without unbinding the ports and bind > >>>> to UIO or something. What we need to do is boot the guest, reserve > >>>> huge pages, and run testpmd (keeping its kernel driver as > >>>> "virtio-pci"). In pci_scan_one(): > >>>> > >>>> if (!ret) { > >>>> if (!strcmp(driver, "vfio-pci")) > >>>> dev->kdrv = RTE_KDRV_VFIO; > >>>> else if (!strcmp(driver, "igb_uio")) > >>>> dev->kdrv = RTE_KDRV_IGB_UIO; > >>>> else if (!strcmp(driver, "uio_pci_generic")) > >>>> dev->kdrv = RTE_KDRV_UIO_GENERIC; > >>>> else > >>>> dev->kdrv = RTE_KDRV_UNKNOWN; > >>>> } else > >>>> dev->kdrv = RTE_KDRV_UNKNOWN; > >>>> > >>>> I think it should be going to RTE_KDRV_UNKNOWN > >>>> (driver=="virtio-pci") here. > >>> Sorry, I simply overlook that. I was thinking it will quit here for > >>> the RTE_KDRV_UNKNOWN case. > >>> > >>>> I tried to run IO and it could work, > >>>> but I am not sure whether it is safe, and how. > >>> I also did a quick test then, however, with the virtio 1.0 patchset > >>> I sent before, which sets the RTE_PCI_DRV_NEED_MAPPING, resulting to > >>> pci_map_device() failure and virtio pmd is not initiated at all. > >> Then, will the patch work with ioport way to access virtio devices? > > Yes. > > > >>>> Also, I am not sure whether I need to (at least) unbind the > >>>> virtio-pci driver, so that there should have no kernel driver > >>>> running for the virtio device before DPDK using it. > >>> Why not? That's what the DPDK document asked to do > >>> (http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html): > >>> > >>> 3.6. Binding and Unbinding Network Ports to/from the Kernel Modules > >>> > >>> As of release 1.4, DPDK applications no longer automatically unbind > >>> all supported network ports from the kernel driver in use. Instead, > >>> all ports that are to be used by an DPDK application must be bound > >>> to the uio_pci_generic, igb_uio or vfio-pci module before the > >>> application is run. Any network ports under Linux* control will be > >>> ignored by the DPDK poll-mode drivers and cannot be used by the > >>> application. > >> This seems obsolete? since it's not covering ioport. > > I don't think so. Above is for how to run DPDK applications. ioport > > is just a (optional) way to access PCI resource in a specific PMD. > > > > And, above speicification avoids your concerns, that two drivers try > > to manipulate same device concurrently, doesn't it? > > > > And, it is saying "any network ports under Linux* control will be > > ignored by the DPDK poll-mode drivers and cannot be used by the > > application", so that the case you were saying that virtio pmd > > continues to work without the bind looks like a bug to me. > > > > Can anyone confirm that? > > That document isn't accurate. virtio doesn't require binding to UIO > driver if it uses PORT IO. The PORT IO commit said it is because UIO > isn't secure, but avoid using uio doesn't bring more security as virtio > PMD still could ask device to DMA into any memory. > The thing we at least we might do is fail in virtio_resource_init if > kernel driver is still manipulating this device. This saves the effort > users use blacklist option and avoids the driver conflict. +1 for checking kernel driver in use