From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) by dpdk.org (Postfix) with ESMTP id A2A27199AF for ; Thu, 21 Sep 2017 17:21:09 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) by serv108.segi.ulg.ac.be (Postfix) with ESMTP id B0C8B200E2DE for ; Thu, 21 Sep 2017 17:21:08 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id A2419129E9A3 for ; Thu, 21 Sep 2017 17:21:08 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pMkYDhS5rLDV for ; Thu, 21 Sep 2017 17:21:08 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 8BC92129E88D for ; Thu, 21 Sep 2017 17:21:08 +0200 (CEST) Date: Thu, 21 Sep 2017 17:21:08 +0200 (CEST) From: tom.barbette@ulg.ac.be To: dev@dpdk.org Message-ID: <371456982.11145391.1506007268500.JavaMail.zimbra@ulg.ac.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [139.165.223.24] X-Mailer: Zimbra 8.7.1_GA_1670 (ZimbraWebClient - GC61 (Linux)/8.7.1_GA_1670) Thread-Index: UPurxgUzyJcIDCgbD1lUrPsF7doSYg== Thread-Topic: Cannot allocate mempool with --no-huge since DPDK 16.07 Subject: [dpdk-dev] Cannot allocate mempool with --no-huge since DPDK 16.07 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:21:09 -0000 Hi all, I get a EINVAL since DPDK 16.07 when trying to allocate a mempool with rte_pktmbuf_pool_create. This is when I use --no-huge --vdev=eth_ring0. But this happens before accessing the virtual device in any ways. Which, btw shows the documentation is wrong as it indicates : EINVAL - cache size provided is too large, or priv_size is not aligned. Which is not the problem here (tried cache_size of 0, 64,256 and priv_size is 0). EINVAL can obviously come from elswhere. Any idea? Something changed in involved subsystems since 16.07? Thanks, Tom