From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by dpdk.org (Postfix) with ESMTP id 882D98001 for ; Mon, 24 Nov 2014 06:35:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5299; q=dns/txt; s=iport; t=1416807957; x=1418017557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nZtThqU5u93Hke+jEVopKqiY1G3EqL2oK2EzU7Vvqds=; b=dnsVBg1yXnx8wzTFkoh1bnVJE8MdAuy4kisWyf08UmHrlvDilXz8zjnz ZVIj4QTVSaL3xOfHh1M6q/64ydpYi+te5m/o+lCDmo2qjC2TdCPo/GXNJ dvwZ/aFdrk/waMJyM0yJRWUZ4owhs84mDCvr0Jal4wCUweobHlMLAPpK3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAKvFclStJV2T/2dsb2JhbABbgw5VWQTLcYZyAoEVFgEBAQEBfYQDAQEEJ1IQAgEIDgouMiUCBA4FiEHNdgEBAQEBAQEBAQEBAQEBAQEBARqRCweETgWLaYZ/hGWHNIE0kVyECoN9eIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="374695109" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 24 Nov 2014 05:45:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAO5jtin001371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 05:45:55 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.173]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 23 Nov 2014 23:45:55 -0600 From: "Sujith Sankar (ssujith)" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH v3 6/6] DPDK changes for accommodating ENIC PMD Thread-Index: AQHQBuhEwvzmIS/5eU6QDhmBVMOFxJxvTucAgAC34wA= Date: Mon, 24 Nov 2014 05:45:54 +0000 Message-ID: References: <1416758899-1351-1-git-send-email-ssujith@cisco.com> <1416758899-1351-7-git-send-email-ssujith@cisco.com> <20141124001744.GA7751@localhost.localdomain> In-Reply-To: <20141124001744.GA7751@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.127.149.201] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <91B2DB14ABB8A64EA137722846E6B8A3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , "Prasad Rao \(prrao\)" Subject: Re: [dpdk-dev] [PATCH v3 6/6] DPDK changes for accommodating ENIC PMD 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: Mon, 24 Nov 2014 05:35:11 -0000 On 24/11/14 5:47 am, "Neil Horman" wrote: >On Sun, Nov 23, 2014 at 09:38:19PM +0530, Sujith Sankar wrote: >> Signed-off-by: Sujith Sankar >> --- >> config/common_linuxapp | 5 +++++ >> lib/Makefile | 1 + >> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 7 +++++++ >> lib/librte_eal/linuxapp/eal/include/eal_pci_init.h | 1 + >> mk/rte.app.mk | 4 ++++ >> 5 files changed, 18 insertions(+) >>=20 >> diff --git a/config/common_linuxapp b/config/common_linuxapp >> index 57b61c9..3c091e7 100644 >> --- a/config/common_linuxapp >> +++ b/config/common_linuxapp >> @@ -210,6 +210,11 @@ CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=3D4 >> CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=3D-1 >> =20 >> # >> +# Compile burst-oriented Cisco ENIC PMD driver >> +# >> +CONFIG_RTE_LIBRTE_ENIC_PMD=3Dy >> + >> +# >> # Compile burst-oriented VIRTIO PMD driver >> # >> CONFIG_RTE_LIBRTE_VIRTIO_PMD=3Dy >> diff --git a/lib/Makefile b/lib/Makefile >> index e3237ff..1911790 100644 >> --- a/lib/Makefile >> +++ b/lib/Makefile >> @@ -43,6 +43,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) +=3D librte_cmdline >> DIRS-$(CONFIG_RTE_LIBRTE_ETHER) +=3D librte_ether >> DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) +=3D librte_pmd_e1000 >> DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) +=3D librte_pmd_ixgbe >> +DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) +=3D librte_pmd_enic >> DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) +=3D librte_pmd_i40e >> DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) +=3D librte_pmd_bond >> DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) +=3D librte_pmd_ring >> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c >>b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c >> index c776ddc..6bf8f2e 100644 >> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c >> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c >> @@ -736,6 +736,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev) >> maps[i].offset =3D reg.offset; >> maps[i].size =3D reg.size; >> dev->mem_resource[i].addr =3D bar_addr; >> + dev->mem_resource[i].len =3D reg.size; >> } >> =20 >> /* if secondary process, do not set up interrupts */ >> @@ -791,4 +792,10 @@ pci_vfio_is_enabled(void) >> { >> return vfio_cfg.vfio_enabled; >> } >> + >> +int >> +pci_vfio_container_fd(void) >> +{ >> + return vfio_cfg.vfio_container_fd; >> +} >You should move this function definition to a separate patch and put it >earlier >in the series, as you call this function two patches back. Thanks for the comment, Neil. I shall move this to a separate patch and put it earlier in the series. > >Also, this gives me pause, as it seems like you're working around the >VFIO api. >>From what I see, you just use this to get an fd that you can use in an >ioctl to >set some DMA settings. First off, theres already a function called >pci_vfio_get_container_fd, which does exactly what you are doing here, >with >additional safety checking. > >However, even though there is an existing function to do what you want, I >would >recommend that you not use it for your purposes. Whenever you expose >something >like a file descriptor, you run the risk of multiple accessors racing >trying to >set/unset features and preform operations. It would be better if you >could add >apropriate api calls to vfio interface to set what you want. That way the >library can add appropriate locking if/when needed I see that vfio_cfg.vfio_container_fd is obtained and stored in pci_vfio_enable(), and this is not modified later. ENIC PMD needs it to add the IOMMU mapping for buffers used for communicating with adapter firmware. That=B9s just adding an entry, and container fd is just passed as an argument. So the following addition in eal_pci_vfio.c should be sufficient. Since vfio_cfg is per process, I do not think that any other checking is required. int pci_vfio_map_dma(struct vfio_iommu_type1_dma_map *dma_map) { return ioctl(vfio_cfg.vfio_container_fd, VFIO_IOMMU_MAP_DMA, dma_map); } Does this look alright? Do you think that I=B9ve missed out anything here? Thanks, -Sujith > >Neil > >> #endif >> diff --git a/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h >>b/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h >> index d758bee..c9e9e40 100644 >> --- a/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h >> +++ b/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h >> @@ -71,6 +71,7 @@ int pci_uio_map_resource(struct rte_pci_device *dev); >> =20 >> int pci_vfio_enable(void); >> int pci_vfio_is_enabled(void); >> +int pci_vfio_container_fd(void); >> int pci_vfio_mp_sync_setup(void); >> =20 >> /* map VFIO resource prototype */ >> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >> index 285b65c..95c652f 100644 >> --- a/mk/rte.app.mk >> +++ b/mk/rte.app.mk >> @@ -186,6 +186,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y) >> LDLIBS +=3D -lrte_pmd_vmxnet3_uio >> endif >> =20 >> +ifeq ($(CONFIG_RTE_LIBRTE_ENIC_PMD),y) >> +LDLIBS +=3D -lrte_pmd_enic >> +endif >> + >> ifeq ($(CONFIG_RTE_LIBRTE_VIRTIO_PMD),y) >> LDLIBS +=3D -lrte_pmd_virtio_uio >> endif >> --=20 >> 1.9.1 >>=20 >>=20