From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 087D88E6A for ; Thu, 21 Jan 2016 15:47:44 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id u188so229425406wmu.1 for ; Thu, 21 Jan 2016 06:47:44 -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=PnxGXBQC/LhTFY7sq/AhiL015COyNXma8EacTICZxEs=; b=N4hQodXkEB4E3cP6f/zX51pPsCMKeVObBelkY6l91BYszsk5J0Jb1e1w2RW0aAskKL 4LKqQj30Sapr2KIAmlH/kknn+3/bCA6MyKe1Q4/PqwF0j09gutx0wE4kB0NxvdBjmU2X MZjoDBHiEmuc6290Vw+jQXRNGY6N/4WZpD/cgDsOs8Hj/FDH81c6057G3o0BZjMVvu9k mMWijiz6smzFsZs8PpBiFLhh7lcg/fxbKiaBK2Sn2MKPf740HVjpiEYfPaHZnPNsTqpV CNe1cDKOyYoxmFQnLT8R4QTI5Fgju2XHo2L5wDzQ6v5yIorcHzXas4Se1PsmAkS27P/y Jiyw== 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=PnxGXBQC/LhTFY7sq/AhiL015COyNXma8EacTICZxEs=; b=IlMZQKXQlzYXmSNifz8HXdFrI29PSgMgPao1CNboL5KFhqGepss53Ky5dVRmYf5Iil gxDviQ1sy3niCXTz3XZWGEahA4cV9oSHXLT3r0XqCG1jutK1+6et0gFzkbbTxmoU/3Vs XNhSluvqkJUGuBx6TQStpVn2cgY22jyUa+CZAMZNL6vxVbc3n4rniTkrBTg3K7IePP+0 gaKjiFMpPVMpvOswSrs9wTqWc5TbKuU1WMgBTP1awQ17xIapXavOuZ/WWS27X3ruN+mQ xpYYsgZGPeKF8jbSaFq3VCii/8rM1wLNT4kmS0v2ZJXXyky5uuS+m0rHhbnZDBJwUOIB ewyw== X-Gm-Message-State: AG10YOSJ6qH+j2BM4IicxsAZQvAOdNYlUq0Qr9jkb7z449z3DGU7F9kwlz2F5qhyU02ukmpX X-Received: by 10.28.218.78 with SMTP id r75mr11144473wmg.7.1453387663800; Thu, 21 Jan 2016 06:47:43 -0800 (PST) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id t9sm1782594wjf.33.2016.01.21.06.47.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 06:47:42 -0800 (PST) From: Thomas Monjalon To: Santosh Shukla Date: Thu, 21 Jan 2016 15:46:42 +0100 Message-ID: <4435068.Ty9Jpve82j@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: <1453229842-15310-1-git-send-email-sshukla@mvista.com> <1491599.cgkG2mIphR@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Alex Williamson Subject: Re: [dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode 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, 21 Jan 2016 14:47:44 -0000 2016-01-21 17:34, Santosh Shukla: > On Thu, Jan 21, 2016 at 4:58 PM, Thomas Monjalon > wrote: > > 2016-01-21 16:43, Santosh Shukla: > >> David Marchand wrote: > >> > This is a mode (specific to vfio), not a new kernel driver. > >> > > >> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e.. > >> __VFIO and __VFIO_NOIOMMU. > > > > Woaaa! Your logic is really disappointing :) > > Specific to VFIO => append _NOIOMMU > > If it's for VFIO, it should be called VFIO (that's my logic). > > > I am confused by reading your comment. vfio works for default iommu > and now with noiommu. drv->kdrv need to know driver mode for vfio > case. So that user can simply read drv->kdrv value in their driver and > accordingly use vfio rd/wr api for example {pread/pwrite}. This is how > rte_eal_pci_vfio_read/write_bar() api implemented. Sorry I don't understand. Why EAL read/write functions should be different depending of the VFIO mode? > And Yes it is called VFIO but with with specifics appended in it. > > >> > How come we need to distinguish between with/without iommu modes ? > >> > >> By default vfio framework assumes iommu i.,e., iommu present. Unless user > >> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we > >> care to parse vfio driver for _noiommu_ mode only. > > > > Why do we care to parse noiommu only? > > Because pmd drivers example virtio can work with vfio only in > _noiommu_ mode. In particular, virtio spec 0.95 / legacy virtio. Please could you explain the limitation (except IOMMU availability)? > So at > the initialization (example .. virtio-net) of such pmd driver, pmd > driver should know that vfio-with-noiommu mode enabled or not? for > that pmd driver simply checks drv->kdrv value. If a check is needed, I would prefer using your function pci_vfio_is_noiommu() and remove driver modes from struct rte_kernel_driver. > Currently virtio-net > pmd driver does resource parsing then resource init for interfaces > like UIO/ioport, I intend to do same but only parsing, as resource > init for vfio case already taken care by pci_xx_vfio_map() api in > virtio-net pmd driver (refer Yaun recently virtio 1.0 recently > submitted rte_eal_pci_map patch) > > Also Yuan in one of earlier thread inclined to remove all the resource > parsing api from virtio-net pmd driver. Pl. refer this thread [1] > > [1] http://dpdk.org/dev/patchwork/patch/9862/ Yes he said "we should try to avoid getting UIO/VFIO stuff inside virtio pmd driver". I agree we must try to have those abstractions in EAL. The only exception seems to be the switch ioport/PCI bar to read/write in virtio. > > Even if virtio cannot work in an IOMMU case, there is no reason to add > > a VFIO_NOIOMMU type here. > > > >> > Should not vfio behave the same way from an api point of view ? > >> > > >> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc.. > >> I am little confused on your question, do you see any issue in vfio bar > >> rd/wr api implementation? > > > > I think you should just consider the VFIO API and let the noiommu option > > as a kernel configuration detail. > > vfio apis _are_ considered at low level rd/wr implementation, Has > nothing to do with iommu/noiommu mode. See pci_vfio_read/write_bar() > implementation, they are using pread64/pwrite64() vfio rd/wr api. So you agree that the VFIO API abstract the iommu availability details?