From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 37888B3CD for ; Thu, 18 Sep 2014 20:07:04 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XUgBt-0003W7-8t; Thu, 18 Sep 2014 14:12:31 -0400 Date: Thu, 18 Sep 2014 14:12:24 -0400 From: Neil Horman To: "Richardson, Bruce" Message-ID: <20140918181224.GO20389@hmsreliant.think-freely.org> References: <1411037752-8000-1-git-send-email-bruce.richardson@intel.com> <59AF69C657FD0841A61C55336867B5B0343F3406@IRSMSX103.ger.corp.intel.com> <20140918150312.GF20389@hmsreliant.think-freely.org> <2042613.z76ONrFlF0@xps13> <20140918155044.GI20389@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B0343F358D@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59AF69C657FD0841A61C55336867B5B0343F358D@IRSMSX103.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used RHEL 6) 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: Thu, 18 Sep 2014 18:07:05 -0000 On Thu, Sep 18, 2014 at 04:01:32PM +0000, Richardson, Bruce wrote: > > -----Original Message----- > > From: Neil Horman [mailto:nhorman@tuxdriver.com] > > Sent: Thursday, September 18, 2014 4:51 PM > > To: Thomas Monjalon > > Cc: Richardson, Bruce; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used RHEL > > 6) > > > > On Thu, Sep 18, 2014 at 05:38:58PM +0200, Thomas Monjalon wrote: > > > Hi Neil, > > > > > > 2014-09-18 11:03, Neil Horman: > > > > Thank you, I've reproduced the problem here, and you're right, it is a > > > > compiler bug, but I really hate the idea of just throwing braces around > > > > something to shut the compiler up, especially when the compiler has since > > > > been fixed. Looking at it a bit more closely it seems like the the thing > > > > to do is actually just consistently use rte_mbuf_refcnt_set, since thats > > > > what the rte_mbuf header documentation says to do, and protects you if the > > > > internal structure changes, as well as prevents you from having to spread > > > > ifdef RTE_MBUF_REFCNT all over the place. > > > > > > > > This patch does a bit more than that too. With a little creative > > > > typedef-ing we don't need the anonymous union at all, and lets us just use > > > > a single refcnt variable, and I think eliminate that odd refcnt_reserved > > > > member of the union, that, as far as I can see, does nothing. > > > > > > > --- a/config/common_linuxapp > > > > +++ b/config/common_linuxapp > > > > @@ -123,7 +123,7 @@ CONFIG_RTE_LOG_HISTORY=256 > > > > CONFIG_RTE_LIBEAL_USE_HPET=n > > > > CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n > > > > CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n > > > > -CONFIG_RTE_EAL_IGB_UIO=y > > > > +CONFIG_RTE_EAL_IGB_UIO=n > > > > CONFIG_RTE_EAL_VFIO=y > > > > > > Hum, indeed this patch does a bit more ;) > > > > > Sorry, meant to clip that out, I was building without kernel headers, so I had > > to disable igb_uio and kni. I'll propose this patch properly if theres > > consensus on the valid bits. > > Neil > > If we get rid of the REFCNT compile-time option (but not the REFCNT_ATOMIC one), then we should be able to get rid of the union, as we can do the atomic/non-atomic entirely inside the refcnt manipulation routines (since a regular uint16_t can be typecast directly to an atomic form of the same). Once we get rid of the union we can get rid of the extra braces that go along with the union, and we can just have the static initialiser cleanly put in the code. > Whaddaya think? > Yeah, that sounds good. Reduces the code complexity by a good amount, makes configuration simpler and allows for easy static initalization. > /Bruce >