From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dirk.lenz@ng4t.com>
Received: from mail.ud15.udmedia.de (ud15.udmedia.de [194.117.254.55])
 by dpdk.org (Postfix) with ESMTP id E86052986
 for <users@dpdk.org>; Mon,  7 Aug 2017 16:07:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=ng4t.com; h=to:from
 :subject:message-id:date:mime-version:content-type
 :content-transfer-encoding; s=k1; bh=nJKVmqPBqqHhlLf+yReOSsRQID6
 Eh3TnL5s7XA8zCs4=; b=Dp1zCLF4NuiXFgPk/GnPnAzOSsQsSUZwRjZUBL6+RZA
 1ENdE1iAmt6HXEBgtxydvzGgxuuYkGGNnhNQurIhVURnnMlasEP9N0CmdrEEVnjw
 6lKsX+DHYHcOMojveK4YNk5On7fUsvfI+h1Xe0JcLpiSdw9eqB7q6uLSmnoyksCY
 =
Received: (qmail 20739 invoked from network); 7 Aug 2017 16:07:24 +0200
Received: from unknown (HELO ?IPv6:2a02:8106:1:f900:2e0:4cff:fe68:158b?)
 (ud15?2p5@2a02:8106:1:f900:2e0:4cff:fe68:158b)
 by mail.ud15.udmedia.de with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256 encrypted,
 authenticated); 7 Aug 2017 16:07:24 +0200
To: "users@dpdk.org" <users@dpdk.org>
From: Dirk-Holger Lenz <dirk.lenz@ng4t.com>
Message-ID: <c578db05-2bcf-7193-9ba4-cc5332c74398@ng4t.com>
Date: Mon, 7 Aug 2017 16:07:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Icedove/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [dpdk-users] virtio doesn't work on some virtual machines
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 14:07:25 -0000

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.