From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8E95BA0546 for ; Wed, 26 May 2021 22:27:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C19E40150; Wed, 26 May 2021 22:27:21 +0200 (CEST) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by mails.dpdk.org (Postfix) with ESMTP id C4B1540143 for ; Wed, 26 May 2021 22:27:19 +0200 (CEST) Received: by mail-ej1-f51.google.com with SMTP id lz27so4464200ejb.11 for ; Wed, 26 May 2021 13:27:19 -0700 (PDT) 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=XSie/TzXvtpZ+KbwPP4r0uPYGD8QKw0rZgX3YxNAsmk=; b=giN9SZdUKDjynywqIiMOlGbRIuIPXDDbg0Hn69YsnGn640Touorj4rPrAgZ+tWWqRm KEFl4gfx8o+hIYiIFBl1RCObXyAd0Z1VTAaOrnub9gRCQgYPTVPL2IRae43CRuuJxcSO bI84UvrRyVcoPKeTmsklpz/kg4p+r/f0B/1O3objDoxSM0Et4R+iAPT9+b449piSNSck A+DwGk9pIawqNKKxhI2rmwnCTvP24nJW4kahdvPT/xapnBeeNm4hLZcQL0m2UwCDCyLv lz9ooVL3uAqjgY+RIreOSHDsXk+KzvA4qiw48cicUyTmkNmuxL24AOVcXNAbVjc3gxHm 0eyA== 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=XSie/TzXvtpZ+KbwPP4r0uPYGD8QKw0rZgX3YxNAsmk=; b=Qu+4d6JtqY1AtSoJk4+lCun3ITdqjPFLLi/Lt9joECCmDAhZBnhTpcRRH830Tc16Xf TPocdrK/bEV4Wxj5QDS+1za3CwfKGEVQiIXrJ7UUgcIpnhJskt2a7xwwPzZu6+2xuzjq HImEqAbYJtIbklKvkTIHAOjpZvV7pZ7mXK88rCGIoPRt0Has0yPPMtMI4sQNS61ZJuih J/RME98VQ6auNoVLtvRLQJ6cneZJMG9XhjLXX4XkU60DR/7Rn2183c280K6CgCkvfwrC QiQ8aSl1ECJsgFsHsDYaUHvf0GkAQvckZwUfgOdzljDTz33x3agk274l9+wRS60wk9p1 n67w== X-Gm-Message-State: AOAM530ZoUcMIyM/IAByEvJ9Dbd+NuluXsk1o5OEtjD28jt3M1kCQ/7j +80Z5mSXkBlD3DYIgnopC0yD8la4nWIj/kw3OSxSkSuBcfU= X-Google-Smtp-Source: ABdhPJzPg9b395Dvjb2zOKTVDyPySbcTiZiYf4rT2FhvjWQ7aI4DY1ROHzhl8sJWbjZ5QjYzymKU0aSRaZjGl6Na/XQ= X-Received: by 2002:a17:906:e0d5:: with SMTP id gl21mr113731ejb.93.1622060839403; Wed, 26 May 2021 13:27:19 -0700 (PDT) MIME-Version: 1.0 References: <20210526105326.2b580fc7@hermes.local> <20210526130311.292c934a@hermes.local> In-Reply-To: <20210526130311.292c934a@hermes.local> From: Sudharshan Krishnakumar Date: Wed, 26 May 2021 13:27:08 -0700 Message-ID: To: Stephen Hemminger Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-users] Issue moving to DPDK 20.11 release X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Sure, yes that will be good way, if DPDK maintainers can resolve it. In the meantime, do you recommend just building all the libraries statically and have the application link statically to DPDK libraries. For example, DPDK doc for PMD , says -> When testpmd is built with shared library, use option -d to load the dynamic PMD for rte_eal_init. Link-> https://doc.dpdk.org/guides/nics/build_and_test.html In this case, eventhough I am including path to the PMD-> i40e and ALL the dependant DPDK libraries(including mbuf and mempool libraries), it is failing here: --> RTE_LOG(ERR, MBUF, "error setting mempool handler\n"); if (mp_ops_name == NULL) mp_ops_name = rte_mbuf_best_mempool_ops(); ret = rte_mempool_set_ops_byname(mp, mp_ops_name, NULL); if (ret != 0) { RTE_LOG(ERR, MBUF, "error setting mempool handler\n"); rte_mempool_free(mp); rte_errno = -ret; return NULL; } ~/dpdk-20.11/examples/packet_ordering/build$ sudo ./packet_ordering -l 4-6 -n 2 --proc-type auto --log-level 7 -m 1024 --file-prefix packet_ordering -d /usr/local/lib/x86_64-linux-gnu/librte_eal.so -d /usr/local/lib/x86_64-linux-gnu/librte_net_i40e.so -d /usr/local/lib/x86_64-linux-gnu/librte_reorder.so -d /usr/local/lib/x86_64-linux-gnu/librte_ethdev.so -d /usr/local/lib/x86_64-linux-gnu/librte_mempool.so.21 -d /usr/local/lib/x86_64-linux-gnu/librte_mbuf.so -d /usr/local/lib/x86_64-linux-gnu/librte_ring.so -d /usr/lib/x86_64-linux-gnu/libnuma.so.1 -d /usr/local/lib/x86_64-linux-gnu/librte_kvargs.so.21 -d /usr/local/lib/x86_64-linux-gnu/librte_net.so.21 -d /usr/local/lib/x86_64-linux-gnu/librte_meter.so.21 -b 0000:31:00.0 -b 0000:31:00.1 -b 0000:05:00.0 -b 0000:06:00.0 -b 0000:07:00.0 -b 0000:08:00.0 -- -p 0xf --disable-reorder EAL: Detected 72 lcore(s) EAL: Detected 2 NUMA nodes EAL: Auto-detected process type: PRIMARY EAL: Multi-process socket /var/run/dpdk/packet_ordering/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: using IOMMU type 1 (Type 1) EAL: Ignore mapping IO port bar(1) EAL: Ignore mapping IO port bar(4) EAL: Probe PCI driver: net_i40e (8086:1572) device: 0000:31:00.2 (socket 0) EAL: Ignore mapping IO port bar(1) EAL: Ignore mapping IO port bar(4) EAL: Probe PCI driver: net_i40e (8086:1572) device: 0000:31:00.3 (socket 0) EAL: No legacy callbacks, legacy socket not created reorder disabled MBUF: error setting mempool handler EAL: Error - exiting with code: 1 Cause: Invalid argument thanks, Sudha On Wed, May 26, 2021 at 1:03 PM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Wed, 26 May 2021 12:41:21 -0700 > Sudharshan Krishnakumar wrote: > > > Hi Stephen, > > > > Normal for dynamically linked shared libraries, linker should load the > > dependant libraries > > based on library path under-> /etc/ld.so.conf.d$ cat > x86_64-linux-gnu.conf > > # Multiarch support > > /usr/local/lib/x86_64-linux-gnu > > /lib/x86_64-linux-gnu > > /usr/lib/x86_64-linux-gnu > > > > I do have the /usr/local/lib/x86* path, which is where DPDK 20.11 > > shared(*.so) libraries have been installed. > > But during launch of application, application does not seem to load those > > libraries. Normally this method works. > > Is this a DPDK issue. > > > > In any case, I followed your suggestion, did ldd -v > packet_ordering-shared, > > to get the dependencies, and manually passed the > > paths to the application, but there is another error now-> MBUF: error > > setting mempool handler > > > > That is true for normal linked in libraries (ie what ldd shows). > The DPDK is doing explicit dlopen to load poll-mode-drivers. > > I would prefer that DPDK was smarter in this area (more like the Linux > kernel) > so that it could have a catalog of PCI device vendor/id table and > automatically > load the PMD; but that capability is not part of the current versions. > > You have to do use -d to load the right .so > >