From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v3 11/29] eal: generic implementation for I/O
 device read/write access
Date: Mon, 16 Jan 2017 16:47:24 +0530
Message-ID: <20170116111722.GA19186@localhost.localdomain>
References: <1482832175-27199-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <1484212646-10338-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <1484212646-10338-12-git-send-email-jerin.jacob@caviumnetworks.com>
 <2622450.7mMCSCBjjk@xps13>
 <20170116032640.GA6271@localhost.localdomain>
 <20170116110127.GA15056@bricha3-MOBL3.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, <dev@dpdk.org>,
 <konstantin.ananyev@intel.com>, <jianbo.liu@linaro.org>,
 <viktorin@rehivetech.com>, <santosh.shukla@caviumnetworks.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0078.outbound.protection.outlook.com [104.47.41.78])
 by dpdk.org (Postfix) with ESMTP id C9ADE1DB1
 for <dev@dpdk.org>; Mon, 16 Jan 2017 12:17:49 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <20170116110127.GA15056@bricha3-MOBL3.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Jan 16, 2017 at 11:01:28AM +0000, Bruce Richardson wrote:
> On Mon, Jan 16, 2017 at 08:56:41AM +0530, Jerin Jacob wrote:
> > On Sun, Jan 15, 2017 at 10:29:42PM +0100, Thomas Monjalon wrote:
> > > 2017-01-12 14:47, Jerin Jacob:
> > > > +#define rte_read8_relaxed(addr) \
> > > > +	({ uint8_t __v = *(const volatile uint8_t *)addr; __v; })
> > > 
> > > Why do you prefer a macro over an inline function?
> > 
> > In this case, I thought of avoiding any compiler behavior changes when
> > adding the new EAL APIs. Earlier, drivers were using direct pointer
> > dereference in code, I thought of using the macro to just substitute that to avoid
> > any performance regression due to this change for easy patchset acceptance.
> > 
> > IMO, One line macros are OK and for this specific case Linux also uses
> > readl/writel as macros.
> > 
> > Having said that, If you think it needs to be changed to "static inline", I
> > am fine with that. Let me know.
> > 
> 
> My preference too is to go with static inline functions over macros
> whenever possible.

OK. I will change to static inline then

> 
> /Bruce
> 
> > > It won't provide the same "debuggability".