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 17A9FA0A02 for ; Fri, 16 Apr 2021 21:32:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 906F716191B; Fri, 16 Apr 2021 21:32:19 +0200 (CEST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) by mails.dpdk.org (Postfix) with ESMTP id 0C6501618D9 for ; Fri, 16 Apr 2021 21:32:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 13GJWFp7013902; Fri, 16 Apr 2021 15:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1618601536; bh=kJAJo8DzOCmsoh7FhoDDjdPP5+3m3fJZRAidWytcfDE=; h=From:To:Subject:Date:From; b=SWIEtqpQsi3ujoW8rjFN0lQkvX+m7KOOQGzZauCSz4sEURHyCdeYV65oWCm4hAOfs S0jJWEcDTY/zM/2Zha8ub6AU1350Vi4VitJGIn2BpZbmrZNRNJyOZIFKxAWqS9NRIB zMI8PV0nVQ1U+GFq+tIT4KlVF3dZV0wAVOmYxPaF63lxL3E5MaKw2NPIQqyacMa6JP YECDpCVBXoMlqpVFwPoDj4j8e7lmashurH6ZMPtr0dK/wGbD340jNUotV0D1aW2KLR pv2L2HLp0OG7N3L2TF6l8zo0hMpQZ13hLhhM9T1gL1ATKE9pcUBZC8nM9iikcHMWnd cm192I89wT4bQ== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 13GJWEe0013887 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Fri, 16 Apr 2021 15:32:14 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2176.2; Fri, 16 Apr 2021 12:32:13 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2176.009; Fri, 16 Apr 2021 12:32:13 -0700 From: "Templin (US), Fred L" To: "users@dpdk.org" Thread-Topic: Problems linking DPDK-20.11 libraries to another program Thread-Index: Adcy9zJG7JoX8gIHSkSJt1iRji6Hmg== Date: Fri, 16 Apr 2021 19:32:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 5E4356984C5CA27857EF6AB60E828657284A44317F3E778813C8A9A1E102EE872000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Subject: [dpdk-users] Problems linking DPDK-20.11 libraries to another program 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" Hello, I am at an impasse trying to link DPDK-20.11 libraries with another = program. The other program (call it "testprog") is a large C source code application= that uses standard linux open source build and compile facilities, including Makefile= s, gcc, configure, etc. It is built from about 190 *.[ch] files, with one defining = a single main() for the entire application. I read the DPDK documentation and tried to link the libraries in using the "pkg-config" facility per the recommendations, but I was unable to get pkg-= config to execute out of the "testprog" Makefile. So, I issued the following comma= nds to obtain the results of running pkg-config: fltemplin@aer-dtn:~$ pkg-config --cflags libdpdk fltemplin@aer-dtn:~$ pkg-config --libs libdpdk I then added the results of the commands to the "testprog" Makefile by addi= ng the following lines: CFLAGS +=3D -include rte_config.h -march=3Dnative -I/usr/local/include LDFLAGS +=3D -L/usr/local/lib/x86_64-linux-gnu -Wl,--as-needed -lrte_node -= lrte_graph -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table -lrte_p= ort -lrte_fib -lrte_ipsec -lrte_vhost -lrte_stack -lrte_security -lrte_sche= d -lrte_reorder -lrte_rib -lrte_regexdev -lrte_rawdev -lrte_pdump -lrte_pow= er -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats -lrte= _ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -lrte_distributor -lr= te_cryptodev -lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev= -lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_cmdline -lrte_pci -lr= te_ethdev -lrte_meter -lrte_net -lrte_mbuf -lrte_mempool -lrte_rcu -lrte_ri= ng -lrte_eal -lrte_telemetry -lrte_kvargs Next, I modified the DPDK "helloworld" example main.c to link it into "test= prog" by changing the name to "hello.c" and changing the "main()" declaration to a f= unction call called: "testprog_hello()" which I then called from one of my other "t= estprog" C modules. The diffs for how I modified the helloworld code appear at the e= nd of this message. I was then able to run "make" in the "testprog" directory, and the build co= mpiled and appeared to link everything just fine. However, it appears that the res= ulting "tesprog" binary only increased in size by about 4% over the size it normal= ly builds to without the DPDK libraries. This seems at odds with the fact that the DP= DK "dpdk-helloworld" binary is massively large in comparison especially consid= ering that the helloworld main.c is only 47 lines of C code! The sizes of the bin= aries are shown below: fltemplin@aer-dtn:~$ cd ~/src/testprog/build fltemplin@aer-dtn:~/src/testprog/build$ ls -l testprog* -rwxr-xr-x 1 fltemplin fltemplin 4991800 Apr 16 10:25 testprog.nodpdk -rwxr-xr-x 1 fltemplin fltemplin 5186816 Apr 16 10:32 testprog.withdpdk fltemplin@aer-dtn~/src/testpog/build$: cd ~/src/DPDK/dpdk-20.11/build/examp= les/ fltemplin@aer-dtn:~/src/DPDK/dpdk-20.11/build/examples$ ls -l dpdk-hellowor= ld -rwxr-xr-x 1 fltemplin fltemplin 17834608 Apr 14 14:30 dpdk-helloworld The next question then came to whether my combined testprog/dpdk code would run the same as the native DPDK helloworld example. I ultimately want to set up a NULL network interface when I call "rte_eal_init (argc, argv)" = and so I tried issuing the following invocation of dpdk-helloworld: fltemplin@aer-dtn:~$ sudo ./dpdk-helloworld --vdev net_null0 EAL: Detected 1 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: Probing VFIO support... EAL: VFIO support initialized EAL: Invalid NUMA socket, default to 0 EAL: Invalid NUMA socket, default to 0 EAL: No legacy callbacks, legacy socket not created hello from core 0 So, as you can see, dpdk-helloworld passes the "--vnet" and "net_null0" arg= uments to "rte_eal_init()", which recognizes the arguments and returns success. Bu= t, when I call "rte_eal_init()" out of my testprog using the same arguments the DPD= K service returns the following: fltemplin@aer-dtn:~$ sudo ./testprog EAL: Detected 1 lcore(s) EAL: Detected 1 NUMA nodes EAL: failed to parse device "net_null0" EAL: Unable to parse device 'net_null0' PANIC in testprog_hello(): Cannot init EAL This appears to me that DPDK is failing to initialize basic data structures when run out of my testprog that are initialized fine when run out of the dpdk-helloworld binary. That the code compiles and links is encouraging, but the fact that the binary size for my combined testprog/helloworld is significantly smaller than the size of dpdk-helloworld alone seems very suspicious. I feel I must be missing something very basic - does anyone recognize these conditions and have insights about how to fix? Thanks - Fred As previously mentioned, see below for my source code changes to link helloworld into testprog: *** ~/src/DPDK/dpdk-20.11/examples/helloworld/main.c 2021-04-14 13:59:16.22= 4073175 -0700 --- ~/src/testprog/src/hello.c 2021-04-16 09:46:42.142210166 -0700 *************** *** 2,7 **** --- 2,14 ---- * Copyright(c) 2010-2014 Intel Corporation */ =20 + #ifdef HAVE_CONFIG_H + #include "config.h" + #elif defined(_MSC_VER) + #include "config-msvc.h" + #endif +=20 + #ifdef ENABLE_DPDK_TEST #include #include #include *************** *** 25,32 **** --- 32,47 ---- } =20 int + #ifdef ENABLE_DPDK_TEST + testprog_hello() + { + char *args[] =3D { "openvpn", "--vdev", "net_null0" }; + char **argv =3D args; + int argc =3D 3; + #else main(int argc, char **argv) { + #endif int ret; unsigned lcore_id; =20 *************** *** 45,47 **** --- 60,63 ---- rte_eal_mp_wait_lcore(); return 0; } + #endif