From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH v2 6/9] app/procinfo: add code for debug
	crypto
Date: Sun, 28 Oct 2018 08:29:18 -0700
Message-ID: <20181028082918.2020a5c5@xeon-e3>
References: <20181023135751.21536-1-vipin.varghese@intel.com>
 <20181024064805.23197-1-vipin.varghese@intel.com>
 <20181024064805.23197-6-vipin.varghese@intel.com>
 <3AEA2BF9852C6F48A459DA490692831F2A3BE6A5@irsmsx110.ger.corp.intel.com>
 <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2B4F8E@BGSMSX101.gar.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "Pattan, Reshma" <reshma.pattan@intel.com>, "dev@dpdk.org"
 <dev@dpdk.org>, "Tahhan, Maryam" <maryam.tahhan@intel.com>, "Patel, Amol"
 <amol.patel@intel.com>, "Tummala, Sivaprasad"
 <sivaprasad.tummala@intel.com>, "Byrne, Stephen1"
 <stephen1.byrne@intel.com>, "Glynn, Michael J" <michael.j.glynn@intel.com>
To: "Varghese, Vipin" <vipin.varghese@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com
 [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id 380664F91
 for <dev@dpdk.org>; Sun, 28 Oct 2018 16:29:27 +0100 (CET)
Received: by mail-pf1-f193.google.com with SMTP id a19-v6so2765119pfo.8
 for <dev@dpdk.org>; Sun, 28 Oct 2018 08:29:27 -0700 (PDT)
In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2B4F8E@BGSMSX101.gar.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Sat, 27 Oct 2018 04:42:19 +0000
"Varghese, Vipin" <vipin.varghese@intel.com> wrote:

> Hi,
> 
> <snipped>
> 
> > ---
> > +		struct rte_cryptodev_info dev_info = {0};
> > +		struct rte_cryptodev_stats stats = {0};
> > +
> > 
> > Memset for initialization as mentioned in other patch.
> >   
> 
> Yes, I will correct the same as certain compiler flag combination will treat this as incorrect use.
> 
> > +
> > +#define DSP_CRYPTO_FLAG(x) do { \
> > +printf("  - feature flags\n"); \
> > +printf("\t  -- symmetric (%c) asymmetric (%c)" \ " symmetric operation
> > +chaining (%c)\n", \ (x & RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO)?'y':'n', \
> > +(x & RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO)?'y':'n', \ (x &
> > +RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING)?'y':'n'); \ printf("\t  -- CPU
> > +SSE (%c) AVX (%c) AVX2 (%c) AVX512 (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_CPU_SSE)?'y':'n', \ (x &
> > +RTE_CRYPTODEV_FF_CPU_AVX)?'y':'n', \ (x &
> > +RTE_CRYPTODEV_FF_CPU_AVX2)?'y':'n', \ (x &
> > +RTE_CRYPTODEV_FF_CPU_AVX512)?'y':'n'); \ printf("\t  -- Acclerate CPU
> > +AESNI (%c) HW (%c)\n", \ (x & RTE_CRYPTODEV_FF_CPU_AESNI)?'y':'n', \ (x
> > +& RTE_CRYPTODEV_FF_HW_ACCELERATED)?'y':'n'); \ printf("\t  -- INLINE
> > +(%c)\n", \ (x & RTE_CRYPTODEV_FF_SECURITY)?'y':'n'); \ printf("\t  --
> > +ARM NEON (%c) CE (%c)\n", \ (x & RTE_CRYPTODEV_FF_CPU_NEON)?'y':'n', \
> > +(x & RTE_CRYPTODEV_FF_CPU_ARM_CE)?'y':'n'); \ printf("  - buffer
> > +offload\n"); \ printf("\t  -- IN_PLACE_SGL (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_IN_PLACE_SGL)?'y':'n'); \ printf("\t  --
> > +OOP_SGL_IN_SGL_OUT (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_OOP_SGL_IN_SGL_OUT)?'y':'n'); \ printf("\t  --
> > +OOP_SGL_IN_LB_OUT (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_OOP_SGL_IN_LB_OUT)?'y':'n'); \ printf("\t  --
> > +OOP_LB_IN_SGL_OUT (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_OOP_LB_IN_SGL_OUT)?'y':'n'); \ printf("\t  --
> > +OOP_LB_IN_LB_OUT (%c)\n", \ (x &
> > +RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT)?'y':'n'); \ } while (0)
> > 
> > This is a very big macro, better have static function for this instead of macro.
> >   
> 
> There are two thoughts in choosing MACRO over function.
> 1. The information need to display in certain format within the same context. 
> 2. As the API are modified, co locating all at same scope is easier to clean up and correct in future.
> 
> So I feel use of MACRO over function in this instance.


I don't agree with your arguments. Macros, are ugly and error prone. This is not performance
critical so it should be a function. The only reason to use macro's is if it is not possible to
write it as a function (as in a template for code generation).