> On 4 Nov 2019, at 18:27, Burakov, Anatoly <anatoly.bura...@intel.com> wrote: > > On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote: >>> On 25 Oct 2019, at 15:02, Damjan Marion (damarion) <damar...@cisco.com >>> <mailto:damar...@cisco.com>> wrote: >>> >>> >>> >>>> On 25 Oct 2019, at 14:23, Burakov, Anatoly <anatoly.bura...@intel.com >>>> <mailto:anatoly.bura...@intel.com>> wrote: >>>> >>>> On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote: >>>>>> On 25 Oct 2019, at 00:32, Thomas Monjalon <tho...@monjalon.net >>>>>> <mailto:tho...@monjalon.net>> wrote: >>>>>> >>>>>> 24/10/2019 21:09, David Marchand: >>>>>>> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov >>>>>>> <anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> 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 <anatoly.bura...@intel.com >>>>>>>> <mailto:anatoly.bura...@intel.com>> >>>>>>>> --- >>>>>>>> >>>>>>>> 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…
