From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 35F665583 for ; Fri, 24 Mar 2017 17:41:37 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id n11so17487619wma.1 for ; Fri, 24 Mar 2017 09:41:37 -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:in-reply-to:references :mime-version:content-transfer-encoding; bh=s+ltv9gh/kG/3bvVW/ZceE/Xu2cyxrTeL7ngzuaK3WA=; b=BtkRFNIErESdP0zljipSFtl51LDGRcBKZdmuG0zGPbBk7TXU7/BRSSQDqnViRCzAmJ vA0CDqKcnqdk5psBZ8kejlZTRKnG/zyBV4G2OndVuQ6FERfkImftw1QJao6MTPDIV2Uq fGQfjoC0DLcVlGeV/uMNVA+UpR0GaUxFnNyHESaag7Ox0yZq0DiwiDL8O9pfRxVX5xvq 6aoD9OvwRR6gMY2CLKdSYabPXHlWGS5HEhs9O6Q6Tn/zcDyhzCkXruJ8iaxL03gWMbQ0 5aqgQj9acRzlLv7ELBjaosPYPWkyU9N9q04pqT2b+HLZ/xS8/ve/5XUB7W7jfKVcn8WP GtQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=s+ltv9gh/kG/3bvVW/ZceE/Xu2cyxrTeL7ngzuaK3WA=; b=uC/reOBUZx5nd1dEWSvb5emWJRVRRNDwdSWTn9t4nerqrGwRp0Yriv0Uk0ivtKlE26 auhlxoVLRPrcr7JOKoxBbLs48c5u5/CPZD0sRgst8FALFVKFfHxQxpO/uyU2Ez4GEo4e q+aDf8q1X5TuWo4/C+auJ7K4dsy5rkQAMingdybDqgaseiiLCXNczOEi0AAG8IA6y5sO 7SKfoaDZlT6GwUc0HnAMkeVpUpHp3S33Ft4WCSskmSzGtn+GKcTJ2Vd9p+3snKi/vv2T xjhxLgu9+G5Ig+iUPrZfmFR2j0PPC8SOcfCZliHLy+KKs4BHKrPXvo40lY4YJ2Oj1AVl kgcw== X-Gm-Message-State: AFeK/H1UpVFe5yJwRQB9A9Pff4gqEStbmsvJI2ChO6xR0xLMqVeGdUXhifwP8tDGh2krgmKc X-Received: by 10.28.28.16 with SMTP id c16mr4337297wmc.38.1490373696874; Fri, 24 Mar 2017 09:41:36 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id 134sm3066735wmj.6.2017.03.24.09.41.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Mar 2017 09:41:36 -0700 (PDT) Date: Fri, 24 Mar 2017 17:41:34 +0100 From: Olivier Matz To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org, jerin.jacob@caviumnetworks.com Message-ID: <20170324174134.6aab6dfe@platinum> In-Reply-To: <20170324145536.GA17076@bricha3-MOBL3.ger.corp.intel.com> References: <20170223172407.27664-1-bruce.richardson@intel.com> <20170307113217.11077-1-bruce.richardson@intel.com> <20170307113217.11077-3-bruce.richardson@intel.com> <14749117.M51NuFqa78@xps13> <20170324145536.GA17076@bricha3-MOBL3.ger.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 02/14] ring: create common structure for prod and cons metadata X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 16:41:37 -0000 Hi Bruce, On Fri, 24 Mar 2017 14:55:36 +0000, Bruce Richardson wrote: > On Wed, Mar 15, 2017 at 03:01:49PM +0100, Thomas Monjalon wrote: > > clang error below: > > > > 2017-03-07 11:32, Bruce Richardson: > > > + union { > > > + uint32_t sp_enqueue; /**< True, if single producer. */ > > > + uint32_t sc_dequeue; /**< True, if single consumer. */ > > > + }; > > > > error: anonymous unions are a C11 extension > > Olivier, Thomas, feedback on suggestions for fixing this? Note: I'm > still waiting to hear back on what compiler settings are needed to > trigger this error. > > Two immediately obvious options: > * replace the union with a single variable called e.g. "single", i.e. > prod.single indicates single producer, and cons.single indicates > single consumer. The downside of this approach is that it makes the > patch a little bigger - as other code needs to be modified to use the > new name - and is not backward compatible for apps which > may reference this public structure memeber. > * just remove the union without renaming anything, leaving two structure > members called sp_enqueue and sc_dequeue. This uses a little more > space in the structure, which is not a big deal since it needs to fill > a cacheline anyway, but it is backward compatible in that no other > code should need to be modified. > > Other options? My preference is for the first one. Given we are breaking > the ring API anyway, I think we might as well use the shorter name and > eliminate the need for the union, or multiple variables. What about adding RTE_STD_C11 like it's done in rte_mbuf? I didn't try, but since mbuf compiles, it should solve this issue in ring. Regards, Olivier