From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 69B391B1F5 for ; Mon, 8 Oct 2018 18:00:01 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2018 09:00:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,357,1534834800"; d="scan'208";a="270530696" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga006.fm.intel.com with ESMTP; 08 Oct 2018 08:59:57 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.4]) by IRSMSX153.ger.corp.intel.com ([169.254.9.121]) with mapi id 14.03.0319.002; Mon, 8 Oct 2018 16:59:57 +0100 From: "Trahe, Fiona" To: Thomas Monjalon , "Joseph, Anoob" CC: "dev@dpdk.org" , Akhil Goyal , "Anoob Joseph" , "De Lara Guarch, Pablo" , Murthy NSSR , Jerin Jacob , Narayana Prasad , Ankur Dwivedi , Nithin Dabilpuram , Ragothaman Jayaraman , Srisivasubramanian S , Tejasree Kondoj Thread-Topic: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities Thread-Index: AQHUTn5M0q8ELNRtJECzvelXdvYy3aT0V/IAgArwFgCACualAIALc3pA Date: Mon, 8 Oct 2018 15:59:56 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589645898@IRSMSX101.ger.corp.intel.com> References: <1528476325-15585-1-git-send-email-anoob.joseph@caviumnetworks.com> <21787cc6-1151-53e9-a86b-aa008b421fb1@caviumnetworks.com> <46633655.Q4LKdWAF6e@xps> In-Reply-To: <46633655.Q4LKdWAF6e@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTllNzNhMjAtZDMyNS00ZjY4LWJlOWMtMWVmYzI0Nzg0N2Y5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibGh6K1RLd3Y5VFhFQVdxVGxlQjE4STNkMitieGs4VnN6S3AyTStqSThMS2thbDdZV3JWUk9sU3Q3VnN6akRyZCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities 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: Mon, 08 Oct 2018 16:00:02 -0000 Hi Akhil, Joseph, Thomas, Just spotted this now. See below. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Monday, October 1, 2018 11:05 AM > To: Joseph, Anoob > Cc: dev@dpdk.org; Trahe, Fiona ; Akhil Goyal ; Anoob > Joseph ; De Lara Guarch, Pablo ; > Murthy NSSR ; Jerin Jacob > ; Narayana Prasad > ; Ankur Dwivedi > ; Nithin Dabilpuram > ; Ragothaman Jayaraman > ; Srisivasubramanian S ; > Tejasree Kondoj > Subject: Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric = capabilities >=20 > 24/09/2018 13:36, Joseph, Anoob: > > Hi Fiona, > > > > Can you please comment on this? > > > > We are adding all capabilities of octeontx-crypto PMD as a macro in > > otx_cryptodev_capabilites.h file and then we are using it from > > otx_cryptodev_ops.c. This is the approach followed by QAT crypto PMD. A= s > > per my understanding, this is to ensure that cryptodev_ops file remains > > simple. For other PMDs with fewer number of capabilities, the structure > > can be populated in the .c file itself without the size of the file > > coming into the picture. > > > > But this would cause checkpatch to report error. Akhil's suggestion is > > to move the entire definition to a header and include it from the .c > > file. I believe, the QAT approach was to avoid variable definition in > > the header. What do you think would be a better approach here? >=20 > I think we should avoid adding some code in a .h file. > And it is even worst when using macros. >=20 > I suggest defining the capabilities in a .c file. > If you don't want to bloat the main .c file, you can create a function > defined in another .c file. >=20 I can't remember all the variations we tried, but there were a few. I think the macro works well in this case.=20 What is the issue we need to solve?