06/11/2019 14:48, David Marchand:
> On Fri, Oct 25, 2019 at 2:23 PM Burakov, Anatoly
> <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> wrote:
> > >>
> > >> 24/10/2019 21:09, David Marchand:
> > >>> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov
> > >>> <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>
> > >>>> ---
> > >>>>
> > >>>> 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.
>
> The issue on VFIO_DEFAULT_CONTAINER seems fixed.
> The deprecation had been announced (even if it was for 20.02) and we
> have a replacement.
>
> So I am for taking this patch.
> Any objection?
I agree to remove these functions.
