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 B22FFA0A02 for ; Fri, 16 Apr 2021 22:04:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 36AF7161D46; Fri, 16 Apr 2021 22:04:00 +0200 (CEST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) by mails.dpdk.org (Postfix) with ESMTP id 38394161D34 for ; Fri, 16 Apr 2021 22:03:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 13GK3rKI005342; Fri, 16 Apr 2021 16:03:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1618603434; bh=s0NPFL0WY0zhuO32G0CcxRjwxZ9b0IfRphRrEdk4kpk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=SooOPm2IYw7+WEOB19aDRRlt/DUnqbq1+NrbdDFAl/X8Ap3FYPsN6QrJULwKeudat WyXAw2eF8RuUXMGlNOHD+TPPdXm9EGrOlgPnZrhc/YX/qjmVH9ei8vu7UJ6zO8T2y+ ZoQElOFNc+YcWf9mjK4djCB8f2gzscJH7OajR6KYX5y98Ri+sFyCxzKl/g3LXGRqQl hwse4FzEJAZY/MNGPlmmKk0hKyIGE+d3Z0f+dTl8HRMDgsJQn7kHdKXsSY37G5HnxA SMWOf61LV7jb/YHURMjg/HHtT5cbUuNTCQ18N0mpkSUUL+kX0N5awkpELlGztGrV4Z zJMKkK7wTi0yA== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 13GK3hk6005278 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Fri, 16 Apr 2021 16:03:44 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) 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 13:03:42 -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 13:03:42 -0700 From: "Templin (US), Fred L" To: "users@dpdk.org" Thread-Topic: Problems linking DPDK-20.11 libraries to another program Thread-Index: Adcy9zJG7JoX8gIHSkSJt1iRji6HmgAA5F8Q Date: Fri, 16 Apr 2021 20:03:42 +0000 Message-ID: References: In-Reply-To: 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: 323D7FFDE008BADCCC49D159C2C00B9B1D426AF7F6CFFD34B0CFA75348F2A7692000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Subject: Re: [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" All, I just noticed that the "dpdk-helloworld" binary was massively large because it was built with the "static" option. When I build it as "shared", the resulting binary is appropriately small. However, when I build it as "shared" I get the same failure case that I describe for what I am getting out of my testprog below. I would greatly prefer to link DPDK into my testprog as "shared" and not "static". But, if I link it as "shared" is there some sort of pre-initializ= ation sequence I need to execute before calling "rte_eal_init()"? I would be happy to be pointed to the appropriate documentation. Thanks - Fred > -----Original Message----- > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Templin (US), Fr= ed L > Sent: Friday, April 16, 2021 12:32 PM > To: users@dpdk.org > Subject: [dpdk-users] Problems linking DPDK-20.11 libraries to another pr= ogram >=20 > Hello, I am at an impasse trying to link DPDK-20.11 libraries with anothe= r program. > The other program (call it "testprog") is a large C source code applicati= on that uses > standard linux open source build and compile facilities, including Makefi= les, gcc, > configure, etc. It is built from about 190 *.[ch] files, with one definin= g a single > main() for the entire application. >=20 > I read the DPDK documentation and tried to link the libraries in using th= e > "pkg-config" facility per the recommendations, but I was unable to get pk= g-config > to execute out of the "testprog" Makefile. So, I issued the following com= mands to > obtain the results of running pkg-config: >=20 > fltemplin@aer-dtn:~$ pkg-config --cflags libdpdk > fltemplin@aer-dtn:~$ pkg-config --libs libdpdk >=20 > I then added the results of the commands to the "testprog" Makefile by ad= ding > the following lines: >=20 > 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_port -lrte_fib -lrte_ipsec -lrte_vhost -lrte_stack -lrte= _security -lrte_sched -lrte_reorder -lrte_rib -lrte_regexdev - > lrte_rawdev -lrte_pdump -lrte_power -lrte_member -lrte_lpm -lrte_latencys= tats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro - > lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressd= ev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer > -lrte_hash -lrte_metrics -lrte_cmdline -lrte_pci -lrte_ethdev -lrte_meter= -lrte_net -lrte_mbuf -lrte_mempool -lrte_rcu -lrte_ring -lrte_eal > -lrte_telemetry -lrte_kvargs >=20 > Next, I modified the DPDK "helloworld" example main.c to link it into "te= stprog" by > changing the name to "hello.c" and changing the "main()" declaration to a= function > call called: "testprog_hello()" which I then called from one of my other = "testprog" > C modules. The diffs for how I modified the helloworld code appear at the= end of > this message. >=20 > I was then able to run "make" in the "testprog" directory, and the build = compiled > and appeared to link everything just fine. However, it appears that the r= esulting > "tesprog" binary only increased in size by about 4% over the size it norm= ally builds > to without the DPDK libraries. This seems at odds with the fact that the = DPDK > "dpdk-helloworld" binary is massively large in comparison especially cons= idering > that the helloworld main.c is only 47 lines of C code! The sizes of the b= inaries > are shown below: >=20 > 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/exa= mples/ > fltemplin@aer-dtn:~/src/DPDK/dpdk-20.11/build/examples$ ls -l dpdk-hellow= orld > -rwxr-xr-x 1 fltemplin fltemplin 17834608 Apr 14 14:30 dpdk-helloworld >=20 > The next question then came to whether my combined testprog/dpdk code > would run the same as the native DPDK helloworld example. I ultimately wa= nt > 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: >=20 > 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 >=20 > So, as you can see, dpdk-helloworld passes the "--vnet" and "net_null0" a= rguments > to "rte_eal_init()", which recognizes the arguments and returns success. = But, when > I call "rte_eal_init()" out of my testprog using the same arguments the D= PDK service > returns the following: >=20 > 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 >=20 > This appears to me that DPDK is failing to initialize basic data structur= es > 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? >=20 > Thanks - Fred >=20 > As previously mentioned, see below for my source code changes to link > helloworld into testprog: >=20 > *** ~/src/DPDK/dpdk-20.11/examples/helloworld/main.c 2021-04-14 13:59:16.= 224073175 -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 > + > + #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