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 4100CA0352; Mon, 4 Nov 2019 18:42:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0AACE29C6; Mon, 4 Nov 2019 18:42:54 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id A4B64237 for ; Mon, 4 Nov 2019 18:42:50 +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 orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2019 09:42:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,267,1569308400"; d="scan'208";a="232139790" 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:42:46 -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> <44f3cd8b-14e2-6fad-7eff-ffc774f91a94@intel.com> <5EC607DF-552C-498D-8184-C4B170AEE8D4@cisco.com> From: "Burakov, Anatoly" Message-ID: Date: Mon, 4 Nov 2019 17:42:45 +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: <5EC607DF-552C-498D-8184-C4B170AEE8D4@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 5:34 PM, Damjan Marion (damarion) wrote: > > >> On 4 Nov 2019, at 18:27, Burakov, Anatoly wrote: >> >> 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. > > That was exactly my reading, but I didn’t want to rush into conclusion. Will ask guys to test… > This should make it easier to test: http://patches.dpdk.org/patch/62390/ -- Thanks, Anatoly