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.
Best regards
Dirk
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
drivers
register to dpdk.
While on the primary process the mempool drivers register in this
sequence:
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
process
with mempool index 0 is used in the secondary process with a different
kind
of drivers and different driver specific functions which makes in our
case the
system block at the symlock that never goes to zero.
