[dpdk-users] virtio doesn't work on some virtual machines
dirk.lenz at ng4t.com
Mon Sep 4 10:36:26 CEST 2017
After we fixed a second problem with virtio we didn't see the described
behaviour anymore. We will tell you when it occurs again.
To the second problem:
Our application dynamically opens and closes ethernet ports on request.
This means it calls rte_eth_dev_configure(), rte_eth_tx_queue_setup(),
rte_eth_rx_queue_setup(), rte_eth_dev_start and (later) rte_eth_dev_stop()
in a sequence when it opens an ethernet port and closes it again.
For virtio the rte_eth_rx_queue_setup() doesn't take a new buffer pool
when it already has one. Beside this the buffers taken from the rx side
are also not freed.
Our work around it to call rte_eth_dev_close() and eth_virtio_dev_init()
for the case that the port works on virtio.
On 08/07/2017 04:07 PM, Dirk-Holger Lenz wrote:
> with dpdk 17.08rc4 using shared libriaries and primary/secondary process
> virtio doesn't work on some of our virtual machines.
> The reason for this seems to be the different sequence the mempool
> register to dpdk.
> While on the primary process the mempool drivers register in this
> ring_mp_mc -> 0
> ring_sp_sc ->1
> ring_mp_sc -> 2
> ring_sp_mc -> 3
> stack -> 4
> on some of our virtual machines they register in the same sequence while
> other machines register in this sequence:
> stack -> 0
> ring_mp_mc -> 1
> ring_sp_sc ->2
> ring_mp_sc -> 3
> ring_sp_mc -> 4
> This leads to the effect that the pool which is created by the primary
> with mempool index 0 is used in the secondary process with a different
> of drivers and different driver specific functions which makes in our
> case the
> system block at the symlock that never goes to zero.
More information about the users