From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9F1DFA09E9; Fri, 11 Dec 2020 19:21:39 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D0223AC9E; Fri, 11 Dec 2020 19:21:37 +0100 (CET) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by dpdk.org (Postfix) with ESMTP id 37930AC9B for ; Fri, 11 Dec 2020 19:21:35 +0100 (CET) Received: by mail-lj1-f174.google.com with SMTP id b10so9649566ljp.6 for ; Fri, 11 Dec 2020 10:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gkxoYyGwTHZBXpqPVeOMTVUpBpoRIaLTYTiVQM8PHm4=; b=MryqZmPzqWoRuMO1WgT0jMLR8uHK8gkeYKjvU/N8SF7myGMEHioUBZXCRWc/KIygMu lXpe+XO1zmONjinnnZff1fiVAus6m/OW5rXsEKiNwt5nLX3pPPlzRXSd/goATweU5yZU cs1yVrGfamdsxVTg27uAKmOmOgF4MX13XvHbtsupRWhNrLWbLtmobtBoFXtOU3qBYUej 9JTJVCZwB966AsRz1LC1hefLZR+6DqRxBZmO/YP9EScr19oBkWg06sms7l/Z+1AMtV94 yNuQusQPk/Dx1KrrsoO2G6OiQylP1KrO18MJaxr0btAXcO0Lit+GWXQrJeFxSdcis0ue lhIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gkxoYyGwTHZBXpqPVeOMTVUpBpoRIaLTYTiVQM8PHm4=; b=EZzRtgB3KIP/kUK270GrNaYy+8nNSG2+F+8daG+VdbM/Q7Ea8sQxhe//9hieXDnIc8 xvoqwZYleLVHvJLQrBhDD382lNQq7egaUeWDaWJSJDhI+P+QuXjrBLB85mrwBDD3Ithy Qv4piLb51dKTclKfe7dQPx7yYJXQ2HqNAaVKNdZLxgeXNlS1NvHo5NCk/bTieqX2yA2V zFiFuukFlvHuwISb1VV7Dg2ChmlxvS/Adwzo0QBnlJ9VtUFZhpAXycwYDpziPjX1RvJX z3VV5Oj+cdNAVdORLGPtrpp4CUmk8yfuB74cilzhabYC3mTZNmi8QGmq3B9p+PwTiNQf BFsA== X-Gm-Message-State: AOAM530TQWu7O2Xnt+Rb8GitCcLUsgwlA/H/awIJ5zuMIUVJWhm4TOJy amhd6YSGxJ9OhCvdkCqB53faa5/GAHAjlXNv01UUPEIBawBDrQ== X-Google-Smtp-Source: ABdhPJxwYb8yJSxkmoEFwShojrT2zhGQM7/D4E6piyCcZ1z5GDEl1PEs1WwrwSWecbxtm2gWd0FWkEC7MUSMqaCKXZk= X-Received: by 2002:a2e:9b47:: with SMTP id o7mr3810306ljj.99.1607710893369; Fri, 11 Dec 2020 10:21:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kamaraj P Date: Fri, 11 Dec 2020 23:51:22 +0530 Message-ID: To: dev@dpdk.org Cc: Nageswara Rao Penumarthy Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] rte_pktmbuf_pool_create returns EINVAL 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello All, Looks like the implementation of rte_mempool_populate_default()API changed from dpdk 18.13 to 19.11 version. This to get contiguous memory from the page. Please see the difference in this API. *from dpdk 18.13:* " If we fail to get enough contiguous memory, then we'll go and *from dpdk 19.11* * reserve space in smaller chunks. Here is the palace where we see the failure ? rte_mempool_populate_default() { ...... ....... if (pg_sz == 0 || (mz_flags & RTE_MEMZONE_IOVA_CONTIG)) ret = rte_mempool_populate_iova(mp, mz->addr, iova, mz->len, rte_mempool_memchunk_mz_free, (void *)(uintptr_t)mz); else ret = rte_mempool_populate_virt(mp, mz->addr, mz->len, pg_sz, rte_mempool_memchunk_mz_free, (void *)(uintptr_t)mz); if (ret < 0) { r *te_memzone_free(mz); RTE_LOG(ERR, MEMPOOL, "zero %d\n", ret); ==> fails here* goto fail; } ..... .... } Is there anything that needs to be added from our application to get contiguous memory ? BTW we are using the "-legacy-mem" option. Please suggest if there is any change required w..r.t dpdk 19.11 for the mbuf pool creation ? Thanks, Kamaraj On Thu, Dec 10, 2020 at 11:47 PM Kamaraj P wrote: > Hello All, > > We could observe the issue with rte_mempool_populate_default() API. > Does this lead to fetching contiguous memorywhen allocating it ? > BTW we are using the "legacy mem" option to initialize it. > > Please share if you have more info on this issue. > > > On Tue, Dec 8, 2020 at 12:59 PM Kamaraj P wrote: > >> Hello All, >> >> We are using DDPDK 19.11 and when we call *rte_pktmbuf_pool_create() *API >> allocate memory, >> we could see the EINVAL ( EINVAL - cache size provided is too large, or >> priv_size is not aligned ) return from that above API. >> We are seeing the issue only when we pass the Priv_size value of 64 >> bytes which is aligned to RTE_MBUF_PRIV_ALIGN(8 bytes). >> >> Here is our snippet of our code base: >> #define MBUF_CACHE_SIZE *512 * >> #define MBUF_PRIV_SIZE *64* >> #define FRAME_LEN *9216* >> #define NO_OF_MBUF >> *52736 * >> >> /*define in rte_config.h */ >> #define RTE_PKTMBUF_HEADROOM 128 >> >> pool = rte_pktmbuf_pool_create(name, num_mbufs, >> MBUF_CACHE_SIZE, MBUF_PRIV_SIZE, >> frame_len + RTE_PKTMBUF_HEADROOM, >> rte_socket_id()); >> >> The above check was failed with EINVAL >> >> Could you please suggest if there is any known issue or limitation w.r.t >> 19.11 >> >> Thanks, >> Kamaraj >> >> >> >>