On 06-Nov-19 1:50 PM, Thomas Monjalon wrote:
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.
Nuke them from orbit :)
--
Thanks,
Anatoly
