From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [108.178.13.118]) by dpdk.org (Postfix) with ESMTP id A6E0C44C3 for ; Mon, 11 Mar 2019 14:41:52 +0100 (CET) Received: from ns1.es18.siteground.eu ([37.60.250.193] helo=es18.siteground.eu) by se11.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1h3LBd-0007yo-ID for users@dpdk.org; Mon, 11 Mar 2019 08:41:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=filipjaniszewski.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kW9Xfbj7gu6ezAOkar9hWx4Kw/satkRat9SnJ5iXXYo=; b=xqZtDaAT6KIZsbsl+ZNgdMuzS7 CN0GOuVMCPjOFvLm2BiOAGDOA4BKQEXjfE31gode2cPhbFoJ01RROqyDZx+hHD+9ol+h+C6SMjnMF eaLCdGp0Gs0zFR7x0AqcD3rQ/bcwE+BpjM98Ciu0umgSF748gJZcJchQDvnGY4QgNtzdmPbudbc1t C5Nb8xYt96Q96Gum71QcU4kVv7/rlD0bNLfndvk+rOOR9DB1iRnIGRjIFD0e83244MkzCL8pnUdoZ eqAPhO4DIy6zhLGudHR0N5iImdpJN4ojYyoCwtDPc6MVaFm+99/NsML3Ycmw1vgASCdSuE64OhMuS Yw0/a4tw==; Received: from [89.64.173.160] (port=32960 helo=localhost.localdomain) by es18.siteground.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_34-9f6032f-XX) (envelope-from ) id 1h3LBc-000572-76 for users@dpdk.org; Mon, 11 Mar 2019 14:41:48 +0100 To: "users@dpdk.org" From: Filip Janiszewski Message-ID: <471a48a1-6a9d-5fac-5f1f-3bcc01a12b10@filipjaniszewski.com> Date: Mon, 11 Mar 2019 14:41:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: 37.60.250.193 X-SpamExperts-Domain: es18.siteground.eu X-SpamExperts-Username: 37.60.250.193 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=37.60.250.193@es18.siteground.eu X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ic7OFhM2rARI+tgSWIL7nV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO1v+PcEVtX7KZY7H5dkGCkxVjyn5UrUp4n4yKOOaq9AxezvF4MfpXqmjDm9Q5P2uoFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5lshVt+kBAbFm5D7vY4neG5GvPI2weg8WovFB YtDlTWOCPEeIMuyv9jqjNDaSpvFZLIAU8ez44E+JWMw7Rl2atc5TpWPIhN8E99pKvIrqMrRsmQyB sRL77VLkCKc6a6vT0TyXe6jsMXnTy/o9BuCfMX3QmiJbn9n696EEgf2SAWuTa9woBUmVrXIKzzDn YPqG3Ez1UBrVo0ESRtZrA1oHxwkmr0Aaz6GoBF32dtdAsfG8Ksk+aedMfNWSnJswrtlNQ1mZ/lx+ a1uNuzKVuBqqrwzevvA7ArqeQFEd2navgAkY2pepFFrcjC/YFAkXxYs506PRJ9EUKGYvx19UOOM4 TwwLfsoD4oZRP3TErLIYQ1l7cycw17VtfafqEiav7DzUwgYPJlPEXn9S9fdrynMBWeMx3cNAcGtC tA0+RzveDYEokzERuj3za2AywfU/2B8QB5hQ6nsDvccjqgmDvD9WhzJSqNUrRSRr/KADuR5HJ0ZS QcWO5vOTSMIt370SH74nK6ebN50qxboHaunrOYs9PErvo4YFvOqHx6a22HhANGrmPTSdptl/RWYZ MnzL9k+grAS06DadWOCxjTcPMZ51Uv9iqhwnXF68aSUABGh3xnDEMZvzG/M4fH1zJThj/Ulp4zZ2 20Ob5C4hnl9676dzGm9KSEN8VE2W6KpVFfeSpmt4ZsFvXDqKGU5avWiSv0rdBXHPL9z03XkX6g5s X+rb+RbFXPDolPGUQFwXTAcE7rfbIHwz39/pYKiTebKqBQKCI2klRvIcAD5JiCwcIKdUEjmZ6DOX npsgt8DjfVte0L6Pdl9KRT5/hcKi4mDgb3mUn09oTGNUxO+4ZzBK5mIfOKM4jlzeBRf2XEiC1awZ EQt4DqxxlnCnOQKjhagEKuLSvPMaJFES+ZCu29JtXh+cERvcxj/ohddUYuAf3XG59W0a0zpnN/+F 8KD6uaQzyz5+ X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Subject: [dpdk-users] Can't capture Jumbo Frames with rte.lib.mk X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:41:52 -0000 Hi, (The complete code of the example application is available at https://github.com/fjanisze/dpdk-jf-test) While working on the sample code I made a strange discovery, the same identical piece of software works and capture jumbo frame while compile with $(RTE_SDK)/mk/rte.extapp.mk but it does not work while compiled with $(RTE_SDK)/mk/rte.lib.mk, by that I mean that I cannot capture Jumbo Frames. In the repo I have the same identical piece of code build in two ways, in ./app folder it is built as regular application using a DPDK makefile which calls $(RTE_SDK)/mk/rte.extapp.mk (check the code please). in the ./lib folder you have the same piece of code, but instead of being inside the main(int, char**) function it is placed inside the lib within the test(int,char**) function, to call the test function from the library I've build a little test.c piece of code that do the following: . extern int test(int argc, char**argv); int main(int argc, char** argv) { return test(argc,argv); } . I build the test.c application with: gcc -Wl,--whole-archive -ldpdk -Wl,--no-whole-archive -lmlx4 -lmlx5 -lm -libverbs -lrte_eal -L. -lpthread -lnuma -ldl test.c -ljftest -o test please note that jftest.a must be present in the building dir, this .a file is create by calling make inside ./lib (where the DPDK Makefile is present). If you make sure to configure RTE_SDK then you can build the two test application by: A) Entering ./app and calling make B) Entering ./lib and calling make, then copying from ./lib/build/lib/ the newly create libjftest.a to the ./lib folder and calling the command I show you above to build the test executable: gcc -Wl,--whole-archive -ldpdk -Wl,--no-whole-archive -lmlx4 -lmlx5 -lm -libverbs -lrte_eal -L. -lpthread -lnuma -ldl test.c -ljftest -o test Please note that the code in ./app/main.c and ./lib/main.c is absolutely identical, the only different is that one is build as a lib (.a) and the second as ELF (executable). The build from A can capture Jumbo Frame, the build from B cannot capture Jumbo Frames. I've a test PCAP with two packets, one of size 9022 bytes the other 1522, I send those packets in a loop to my box to test the output of the two test applications, on my development box (A) is generating the following output: . EAL: Detected 28 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: No free hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: PCI device 0000:00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b8 net_e1000_em EAL: PCI device 0000:b3:00.0 on NUMA socket 0 EAL: probe driver: 15b3:1015 net_mlx5 net_mlx5: MPLS over GRE/UDP tunnel offloading disabled due to old OFED/rdma-core version or firmware configuration EAL: PCI device 0000:b3:00.1 on NUMA socket 0 EAL: probe driver: 15b3:1015 net_mlx5 net_mlx5: MPLS over GRE/UDP tunnel offloading disabled due to old OFED/rdma-core version or firmware configuration Running DPDK 19.02.0 Captured pkt, len 9022, nb segs 5 Captured pkt, len 1522, nb segs 1 Captured pkt, len 9022, nb segs 5 Captured pkt, len 1522, nb segs 1 Captured pkt, len 9022, nb segs 5 Captured pkt, len 1522, nb segs 1 Captured pkt, len 9022, nb segs 5 Captured pkt, len 1522, nb segs 1 . . (B) is generating the following output: . EAL: Detected 28 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: No free hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: PCI device 0000:00:1f.6 on NUMA socket 0 EAL: probe driver: 8086:15b8 net_e1000_em EAL: PCI device 0000:b3:00.0 on NUMA socket 0 EAL: probe driver: 15b3:1015 net_mlx5 net_mlx5: MPLS over GRE/UDP tunnel offloading disabled due to old OFED/rdma-core version or firmware configuration EAL: PCI device 0000:b3:00.1 on NUMA socket 0 EAL: probe driver: 15b3:1015 net_mlx5 net_mlx5: MPLS over GRE/UDP tunnel offloading disabled due to old OFED/rdma-core version or firmware configuration Running DPDK 19.02.0 Captured pkt, len 1522, nb segs 1 Captured pkt, len 1522, nb segs 1 Captured pkt, len 1522, nb segs 1 Captured pkt, len 1522, nb segs 1 Captured pkt, len 1522, nb segs 1 . The same piece of software build in two different way generate two different outputs, any suggestion on what might be the issue here? Thanks -- BR, Filip +48 666 369 823