From: Shahaf Shuler <shahafs@mellanox.com>
To: Tom Barbette <barbette@kth.se>, Yongseok Koh <yskoh@mellanox.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] Unregistered mempool in secondary
Date: Thu, 6 Dec 2018 07:18:53 +0000 [thread overview]
Message-ID: <DB7PR05MB442689048FB95E29F8BA3291C3A90@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <1544053277210.30241@kth.se>
Hi Tom,
There is a complete isolation between the resources of each port.
Meaning, mempool cannot be registered on one port and be used on the other (w/o explicit registration).
In order your solution to work, the primary process needs to probe both ports, so that the mempool_walk will happen on both and the pool will be registered to both.
From: Tom Barbette <barbette@kth.se>
Sent: Thursday, December 6, 2018 1:41 AM
To: Shahaf Shuler <shahafs@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
Cc: users@dpdk.org
Subject: Unregistered mempool in secondary
Hi mlx5 maintainers,
Since we're using a second ConnectX 5 NIC plugged to our second CPU socket, we see the following message when flowing packets through that port :
net_mlx5: port 1 using address (0x6000712742c0) of unregistered mempool in secondary process, please create mempool before rte_eth_dev_start()
The secondary process has all of the primary process pools registered via rte_mempool_walk (2 as we have 2 numa nodes). But that address in the error message is actually not between any of the pool->mz->addr_64 + pool->mz->size range. So maybe this comes from an automatically created pool of the primary ? If so, how can we force it to be created before we call eth_dev_start?
We think the only change is that the second port is now a dedicated NIC on the second socket, instead of the second port of the same NIC on the first socket. But we are not 100% sure this is the triggering event. The same test worked before, still with DPDK 18.08.
Thanks,
Tom
next prev parent reply other threads:[~2018-12-06 7:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 23:41 Tom Barbette
2018-12-06 7:18 ` Shahaf Shuler [this message]
2018-12-06 8:18 ` Tom Barbette
2018-12-06 9:21 ` Shahaf Shuler
2018-12-06 9:37 ` Tom Barbette
2018-12-06 9:54 ` Shahaf Shuler
2018-12-06 11:52 ` Tom Barbette
2018-12-06 13:45 ` Shahaf Shuler
2018-12-06 13:49 ` Burakov, Anatoly
2018-12-06 14:53 ` Tom Barbette
2018-12-06 15:28 ` Tom Barbette
2018-12-06 15:39 ` Burakov, Anatoly
2018-12-06 17:27 ` Tom Barbette
2018-12-06 17:50 ` Cliff Burdick
2018-12-06 21:53 ` Tom Barbette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB7PR05MB442689048FB95E29F8BA3291C3A90@DB7PR05MB4426.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=barbette@kth.se \
--cc=users@dpdk.org \
--cc=yskoh@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).