From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id F38991B6D5 for ; Tue, 6 Feb 2018 15:24:24 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48B3A7652A; Tue, 6 Feb 2018 14:24:24 +0000 (UTC) Received: from [10.36.112.19] (ovpn-112-19.ams2.redhat.com [10.36.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04C4760BE0; Tue, 6 Feb 2018 14:24:21 +0000 (UTC) To: Xiao Wang , dev@dpdk.org Cc: jianfeng.tan@intel.com, tiwei.bie@intel.com, yliu@fridaylinux.org, cunming.liang@intel.com, dan.daly@intel.com, zhihong.wang@intel.com References: <20180204145542.38345-1-xiao.w.wang@intel.com> <20180204145542.38345-3-xiao.w.wang@intel.com> From: Maxime Coquelin Message-ID: Date: Tue, 6 Feb 2018 15:24:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180204145542.38345-3-xiao.w.wang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 06 Feb 2018 14:24:24 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/3] net/vdpa_virtio_pci: introduce vdpa sample driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:24:25 -0000 Hi Xiao, On 02/04/2018 03:55 PM, Xiao Wang wrote: > This driver is a reference sample of making vDPA device driver based > on vhost lib, this driver uses a standard virtio-net PCI device as > vDPA device, it can serve as a backend for a virtio-net pci device > in nested VM. > > The key driver ops implemented are: > > * vdpa_virtio_eng_init > Mapping virtio pci device with VFIO into userspace, and read device > capability and intialize internal data. > > * vdpa_virtio_eng_uninit > Release the mapped device. > > * vdpa_virtio_info_query > Device capability reporting, e.g. queue number, features. > > * vdpa_virtio_dev_config > With the guest virtio information provideed by vhost lib, this > function configures device and IOMMU to set up vhost datapath, > which includes: Rx/Tx vring, VFIO interrupt, kick relay. > > * vdpa_virtio_dev_close > Unset the stuff that are configured previously by dev_conf. > > This driver requires the virtio device supports VIRTIO_F_IOMMU_PLATFORM > , because the buffer address written in desc is IOVA. > > Because vDPA driver needs to set up MSI-X vector to interrupt the guest, > only vfio-pci is supported currently. > > Signed-off-by: Xiao Wang > --- > config/common_base | 6 + > config/common_linuxapp | 1 + > drivers/net/Makefile | 1 + > drivers/net/vdpa_virtio_pci/Makefile | 31 + > .../net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c | 1527 ++++++++++++++++++++ > .../rte_vdpa_virtio_pci_version.map | 4 + > mk/rte.app.mk | 1 + > 7 files changed, 1571 insertions(+) > create mode 100644 drivers/net/vdpa_virtio_pci/Makefile > create mode 100644 drivers/net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c > create mode 100644 drivers/net/vdpa_virtio_pci/rte_vdpa_virtio_pci_version.map Is there a specific constraint that makes you expose PCI functions and duplicate a lot of vfio code into the driver? Wouldn't it be better (if possible) to use RTE_PMD_REGISTER_PCI() & co. to benefit from all the existing infrastructure? Maxime