From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 6504B12A8 for ; Wed, 2 Nov 2016 16:21:19 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id a197so147651072wmd.0 for ; Wed, 02 Nov 2016 08:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TIiKFMe06nZqjn0eV8XTNZ1F6zbRj2KQnHMEkhnh0Jg=; b=UB2530H5GgGlmjJKV81g/Auxm6b7fQITWmvLNM6yqbdx4xhaCXTTnU0XjoUNFs3UeZ n1RFTjo0hIyTfqSxXvciMK86f7bLR7+ELeZ9lWwPMROheHtvuB/x1hZqV+snFGokp2Hr c/Oefk2ge++49uQvweVEeAX10dylELwKW+aU5T4N2xEhNYwJ0in24QtEWYi4Hhkezdyd xM602mMV3KKgraTJQOhIFcGCF8JmtIyVU1tKxxmnNsI58TebyC7DiJMMQYvXLYe7CXn9 8PplxCnpDRssmV6Gp0byOWyT4M4+X7y8gIl+U0mhfc2Wu9fzKO79IuYrxG6DYeKNpouu E/Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TIiKFMe06nZqjn0eV8XTNZ1F6zbRj2KQnHMEkhnh0Jg=; b=R1QH9k2W3cDUNxIjKd2oxayAKl6BSVdmeTpvjMffd6JJ6VqjhP++CvKxTLG+6C+9hO T9TX/yf5bYl+cAZDq3KybTaN2J1pMIsIJvCAefCse1YzBOuMX0979KEPNo6rahVGE6KI yM60H7r+XhHDudIcpZkSj1brmnoiqcxzXbvQqoYJRJALey61G+vjIR10zVwWnj4qbAqp VGLqHYxGi8yb30uI3UDabOLNqY4vT8jilAvz7zANOMlazayqAcm0wEjdZAowYhvWwHvy XlcwnuJAlGAXFHMH9MTlVzAR9PRtbpwM0TNveB/BNOS5vIale0dqFCW7w7L94IPBA3j6 +mSw== X-Gm-Message-State: ABUngvcOi+AqwasI54g3OHp+j6/z127fx/d9CvxZR+eNtUb9pwmmxh+RrLTIR9fjsXacs+Kl X-Received: by 10.28.236.205 with SMTP id h74mr3619551wmi.104.1478100079323; Wed, 02 Nov 2016 08:21:19 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id ia7sm3016181wjb.23.2016.11.02.08.21.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 08:21:18 -0700 (PDT) Date: Wed, 2 Nov 2016 16:21:11 +0100 From: Adrien Mazarguil To: "Lu, Wenzhuo" Message-ID: <20161102152111.GD5733@6wind.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09093934068B@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093934068B@shsmsx102.ccr.corp.intel.com> Cc: dev@dpdk.org Subject: Re: [dpdk-dev] dpdk16.11 RC2 package ipv4 reassembly example can't work X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 15:21:20 -0000 Hi all, On Wed, Nov 02, 2016 at 08:39:31AM +0000, Lu, Wenzhuo wrote: > Correct the typo of receiver. > > Hi Adrien, > The change from struct ip_frag_pkt pkt[0] to struct ip_frag_pkt pkt[] will make IP reassembly not working. I think this is not the root cause. Maybe Konstantin can give us some idea. > But I notice one thing, you change some from [0] to [], but others just add '__extension__'. I believe if you add '__extension__' for struct ip_frag_pkt pkt[0], we'll not hit this issue. Just curious why you use 2 ways to resolve the same problem. I've used the __extension__ method whenever the C99 syntax could not work due to invalid usage in the code, e.g. a flexible array cannot be the only member of a struct, you cannot make arrays out of structures that contain such fields, while there is no such constraint with the GNU syntax. For example see __extension__ uint8_t action_data[0] in struct rte_pipeline_table_entry. The C99 could not be used because of test_table_acl.c: struct rte_pipeline_table_entry entries[5]; If replacing ip_frag_pkt[] with __extension__ ip_frag_pkt pkt[0] in rte_ip_frag.h solves the issue, either some code is breaking some constraint somewhere or this change broke the ABI (unlikely considering a simple recompilation should have taken care of the issue). I did not notice any change in sizeof(struct rte_ip_frag_tbl) nor offsetof(struct rte_ip_frag_tbl, pkt) on my setup, perhaps the compilation flags used in your test affect them somehow. Can you confirm whether only reverting this particular field solves the issue? > From: Xu, HuilongX > Sent: Wednesday, November 2, 2016 4:29 PM > To: drien.mazarguil@6wind.com > Cc: Ananyev, Konstantin; Liu, Yu Y; Chen, WeichunX; Lu, Wenzhuo; Xu, HuilongX > Subject: dpdk16.11 RC2 package ipv4 reassembly example can't work > > Hi mazarguil, > I find ip reassembly example can't work with dpdk16.11 rc2 package. > But when I reset dpdk code before 347a1e037fd323e6c2af55d17f7f0dc4bfe1d479, it works ok. > Could you have time to check this issue, thanks a lot. > Unzip password: intel123 > > Test detail info: > > os&kernel:4.2.3-300.fc23.x86_64 > gcc version:5.3.1 20160406 (Red Hat 5.3.1-6) (GCC) > NIC:03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T [8086:15ad] and > 84:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) > package: dpdk16.11.rc2.tar.gz > test steps: > 1. build and install dpdk > 2. build ip_reassembly example > 3. run ip_reassembly > ./examples/ip_reassembly/build/ip_reassembly -c 0x2 -n 4 - -p 0x1 --maxflows=1024 --flowttl=10s > 4. set tester port mtu > ip link set mtu 9000 dev ens160f1 > 5. setup scapy on tester and send packet > scapy > pcap = rdpcap("file.pcap") > sendp(pcap, iface="ens160f1") > 6. sniff packet on tester and check packet > test result: > dpdk16.04 reassembly packet successful but dpdk16.11 reassembly pack failed. > > comments: > file.pcap: send packets pcap file > tcpdump_16.04_reassembly_successful.pcap: sniff packets by tcpdump on 16.04. > tcpdump_reset_code_reassembly_failed.pcap: sniff packets by tcpdump on 16.11 > reset_code_reassembly_successful_.jpg: reassembly a packets successful detail info > dpdk16.11_reassembly_failed.jpg: reassembly a packets failed detail info > -- Adrien Mazarguil 6WIND