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.
--
Thanks,
Anatoly
