From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [130.237.48.193]) by dpdk.org (Postfix) with ESMTP id 2E9895B3A for ; Thu, 6 Dec 2018 09:18:57 +0100 (CET) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id D234D2664; Thu, 6 Dec 2018 09:18:56 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r2VXAhaaz2j4; Thu, 6 Dec 2018 09:18:56 +0100 (CET) Received: from exdb02.ug.kth.se (unknown [192.168.32.112]) by smtp-4.sys.kth.se (Postfix) with ESMTPS id A9B4828C6; Thu, 6 Dec 2018 09:18:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1544084336; bh=3fFQ82R71K/LTYMxA1E0Re0y05ZQfDEdjzOVKBD6T0g=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=XACluOhtslXuWDvRlP10A9+99z/OcBzyXvVAJXFqa8RZkpJfqWzGk1621N7vD2jDF 1P9Abuysz6jZpOaCuDLNWI4I1QcApStCPbiqnZNklFuvLN1gT1+FyspY+WfArkEmEU NYfBJBH1x5ZCFQ8ZYsQbQ6e+ZeCJpXoWBu+vM0bY= Received: from exdb03.ug.kth.se (192.168.32.113) by exdb02.ug.kth.se (192.168.32.112) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Dec 2018 09:18:54 +0100 Received: from exdb05.ug.kth.se (192.168.32.115) by exdb03.ug.kth.se (192.168.32.113) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Dec 2018 09:18:54 +0100 Received: from exdb05.ug.kth.se ([192.168.32.115]) by exdb05.ug.kth.se ([192.168.32.115]) with mapi id 15.00.1367.000; Thu, 6 Dec 2018 09:18:54 +0100 From: Tom Barbette To: Shahaf Shuler , Yongseok Koh CC: "users@dpdk.org" Thread-Topic: Unregistered mempool in secondary Thread-Index: AQHUjO2LmQco5PWHo0uingmMOU1mvKVxTSaggAAQ9qY= Date: Thu, 6 Dec 2018 08:18:54 +0000 Message-ID: <1544084334026.77073@kth.se> References: <1544053277210.30241@kth.se>, In-Reply-To: Accept-Language: fr-FR, sv-SE, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [83.249.19.162] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Unregistered mempool in secondary X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 08:18:57 -0000 Hi Shahaf, Both devices are initialized in the primary with rte_eth_dev_start, and que= ues also (each with their own packet pool). It's just that the secondary re= ad from the initialized queue. If you're mentionning something more to do, then I did not understand. Whic= h function would that be? To ask port 0 to register port 1's pools and vice= versa? Thanks ! Tom ________________________________ De : Shahaf Shuler Envoy=E9 : jeudi 6 d=E9cembre 2018 08:18 =C0 : Tom Barbette; Yongseok Koh Cc : users@dpdk.org Objet : RE: Unregistered mempool in secondary 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 por= ts, so that the mempool_walk will happen on both and the pool will be regis= tered to both. From: Tom Barbette Sent: Thursday, December 6, 2018 1:41 AM To: Shahaf Shuler ; Yongseok Koh 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 r= te_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->s= ize range. So maybe this comes from an automatically created pool of the pr= imary ? If so, how can we force it to be created before we call eth_dev_sta= rt? 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 tes= t worked before, still with DPDK 18.08. Thanks, Tom