From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id B97A811C5 for ; Fri, 4 Nov 2016 11:20:42 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id t79so39917624wmt.0 for ; Fri, 04 Nov 2016 03:20:42 -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=Ei8IqIa6e0mDdVDTwHt6OHDFceO7ps6Ao44uDBK/NQo=; b=aXv/5PSkFav0sba//Yd2jtcqDusBCAYIcoCOqz+oIcQAVIreBUDUvcG/wD0htWuoxW aH4YUbiiT8NF02fIVaKvbH7pMxgimFMD3rBmlTnNhsEzGCtOsdbVWd0DlYjtruJEYC+8 7nQt1eNCB5n9pnxoV9C1kn2SbaxU3qbySTjn08SQ7uJNVggNtSsRJ6yCBk1W5AGBKN8E aBC+iJdKsPiZ6Oe6iXGrdwMXMKDLeHkCdtF4QMjMKlyV8THnqqYZtJrl6EsON35RUAAy lhTIyWkZE7O17O4mSvPYsIqH5Cjv5mlbafvJ3eEajcodp58WJr9pkokhqzpJ5HNFEAaB 7IOA== 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=Ei8IqIa6e0mDdVDTwHt6OHDFceO7ps6Ao44uDBK/NQo=; b=NMUnsoBVq3mkE55lJI4WIeIBAkWE+chL2Qbl1OdZTS9bJWi69+sowsBDuHZNDnyKyM k3HCHi4TyXj4C52aTiedi1R+njPQLrdhCGurhsNGEmBEJrIj2Q0EPRfGSXz+WYyYbTVS M1siPQ8OSCJ6hdlxd6iFsJNGdGiadcuRvAdltp/5SpSjFujeVJWWX6kFW18ZqfNOVAMY y+/+Y3bvgE5ThQBp6ZvI0vZcNexT3lzBuWGOXtUvWTm+2qf/QvHMSh6vlpoyBlvHqADv +v5+TiYrcezcbZG0LB1nht3Tf4oGYDWbJsH9kH5mgZE7x1RPL5ZUc4uKlFjuvDFMVdHW QDCQ== X-Gm-Message-State: ABUngvdEJNBCiHxXKUSgx9gVzTfRLQ3maP0kl6lyZS9Ana5Yvwen8ETn0Lf0tW2dJvyoNzMJ X-Received: by 10.28.210.195 with SMTP id j186mr2449256wmg.73.1478254842430; Fri, 04 Nov 2016 03:20:42 -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 hb5sm13487673wjc.5.2016.11.04.03.20.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 03:20:41 -0700 (PDT) Date: Fri, 4 Nov 2016 11:20:34 +0100 From: Adrien Mazarguil To: "Lu, Wenzhuo" Cc: "Ananyev, Konstantin" , "Liu, Yu Y" , "Chen, WeichunX" , "Xu, HuilongX" , "dev@dpdk.org" Message-ID: <20161104102034.GO5733@6wind.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09093934068B@shsmsx102.ccr.corp.intel.com> <20161102152111.GD5733@6wind.com> <6A0DE07E22DDAD4C9103DF62FEBC090939341118@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC090939341118@shsmsx102.ccr.corp.intel.com> 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: Fri, 04 Nov 2016 10:20:43 -0000 On Fri, Nov 04, 2016 at 06:36:30AM +0000, Lu, Wenzhuo wrote: > Hi Adrien, > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Wednesday, November 2, 2016 11:21 PM > > To: Lu, Wenzhuo > > Cc: Ananyev, Konstantin; Liu, Yu Y; Chen, WeichunX; Xu, HuilongX; > > dev@dpdk.org > > Subject: Re: dpdk16.11 RC2 package ipv4 reassembly example can't work > > > > 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. > Thanks for your explanation. I also checked sizeof(struct rte_ip_frag_tbl). I don't see any change either. > > > > > Can you confirm whether only reverting this particular field solves the issue? > Yes. ip_frag_pkt pkt[0] or even ip_frag_pkt pkt[1] can work but ip_frag_pkt pkt[] cannot :( > Do you like the idea of changing the ip_frag_pkt[] to __extension__ ip_frag_pkt pkt[0]? Yes, restoring the original code (with __extension__) as a workaround until we understand what is going on is safer, that's fine by me. The commit log should explicitly state that weirdness occurs for an unknown reason with the C99 syntax though (compiler bug is also a possibility). -- Adrien Mazarguil 6WIND