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?


-- 
David Marchand

Reply via email to