Re: [dpdk-users] virtio doesn't work on some virtual machines

[Dirk-Holger Lenz <dirk.lenz@ng4t.com>]

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.
>
>
>