From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B214DA0352; Mon, 4 Nov 2019 18:27:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 376072F42; Mon, 4 Nov 2019 18:27:28 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C47FC2BC8 for ; Mon, 4 Nov 2019 18:27:25 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2019 09:27:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,267,1569308400"; d="scan'208";a="232135605" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.92]) ([10.237.220.92]) by fmsmga002.fm.intel.com with ESMTP; 04 Nov 2019 09:27:22 -0800 To: "Damjan Marion (damarion)" Cc: Thomas Monjalon , David Marchand , Shahaf Shuler , Ray Kinsella , dev , Neil Horman , John McNamara , Marko Kovacevic , Bruce Richardson References: <2302363.xZHtmyloc2@xps> <5980E9BB-2D78-43C5-890A-05B6BAC30071@cisco.com> <911c9f45-ef00-0a9c-1e03-473ccbc89b9c@intel.com> <538E3DE4-0F4A-4821-9A22-AE730059B1E3@cisco.com> <2AE0AAEA-CE78-44A2-8E2F-8B8D9756515C@cisco.com> From: "Burakov, Anatoly" Message-ID: <44f3cd8b-14e2-6fad-7eff-ffc774f91a94@intel.com> Date: Mon, 4 Nov 2019 17:27:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2AE0AAEA-CE78-44A2-8E2F-8B8D9756515C@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote: > > >> On 25 Oct 2019, at 15:02, Damjan Marion (damarion) > > wrote: >> >> >> >>> On 25 Oct 2019, at 14:23, Burakov, Anatoly >> > wrote: >>> >>> On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote: >>>>> On 25 Oct 2019, at 00:32, Thomas Monjalon >>>> > wrote: >>>>> >>>>> 24/10/2019 21:09, David Marchand: >>>>>> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov >>>>>> > wrote: >>>>>>> >>>>>>> The rte_vfio_dma_map/unmap API's have been marked as deprecated in >>>>>>> release 19.05. Remove them. >>>>>>> >>>>>>> Signed-off-by: Anatoly Burakov >>>>>> > >>>>>>> --- >>>>>>> >>>>>>> Notes: >>>>>>>    Although `rte_vfio_dma_map` et al. was marked as deprecated in >>>>>>> our documentation, >>>>>>>    it wasn't marked as __rte_deprecated in code. Should we still >>>>>>> remove it? >>>>>> >>>>>> I can see that vpp is still using this api. >>>>>> I would prefer we get some ack from their side. >>>>>> >>>>>> Shahaf? >>>>>> Ray? >>>>>> >>>>>> Do you guys have contact with VPP devs? >>>>> >>>>> +Cc Damjan >>>> Thanks for looping me in. If I remember correctly that was used only >>>> to get mlx PMDs working. >>>> We can remove that calls but then mlx PMDs will stop working unless >>>> there is alternative solution. >>>> From my perspective it is not big issue as we already have native >>>> rdma based mlx support, but i would expect that other people will >>>> complain. >>>> Is there alternative way to tell DPDK about DMA mapping? >>> >>> The rte_vfio_container_dma_map(VFIO_DEFAULT_CONTAINER, ...) is the >>> exact equivalent of the functions being removed. Also, >>> rte_dev_dma_map() is supposed to be the more general DMA mapping API >>> that works with VFIO and with any other bus/device-specific DMA mapping. >>> >>> So yes, a simple search and replace for "rte_vfio_dma_(un)?map(" to >>> "rte_vfio_container_dma_(un)?map(VFIO_DEFAULT_CONTAINER, " should >>> trigger exactly the same behavior. >> >> Done, will be merged after it passes verify jobs… >> >> https://gerrit.fd.io/r/c/vpp/+/22982 > > I just got report that this patch breaks some tests. Is > it RTE_VFIO_DEFAULT_CONTAINER_FD right value to use here? > Maybe i wrongly assumed that when you said VFIO_DEFAULT_CONTAINER, you > meant RTE_VFIO_DEFAULT_CONTAINER_FD… > > — > Damjan > > Yes, i think i can see the bug. Can you rerun the failing test after applying the following patch? diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c index d9541b1220..d7887388f9 100644 --- a/lib/librte_eal/linux/eal/eal_vfio.c +++ b/lib/librte_eal/linux/eal/eal_vfio.c @@ -412,6 +412,9 @@ get_vfio_cfg_by_container_fd(int container_fd) { int i; + if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD) + return default_vfio_cfg; + for (i = 0; i < VFIO_MAX_CONTAINERS; i++) { if (vfio_cfgs[i].vfio_container_fd == container_fd) return &vfio_cfgs[i]; The problem seems to be that we're looking at actual fd, whereas the RTE_VFIO_DEFAULT_CONTAINER_FD value is -1, which will not match anything in that list. -- Thanks, Anatoly