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

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

[Dirk-Holger Lenz]

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.

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

[Dirk-Holger Lenz]

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