[dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities

Trahe, Fiona fiona.trahe at intel.com
Mon Oct 8 17:59:56 CEST 2018


Hi Akhil, Joseph, Thomas,
Just spotted this now.
See below.

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Monday, October 1, 2018 11:05 AM
> To: Joseph, Anoob <Anoob.Joseph at caviumnetworks.com>
> Cc: dev at dpdk.org; Trahe, Fiona <fiona.trahe at intel.com>; Akhil Goyal <akhil.goyal at nxp.com>; Anoob
> Joseph <ajoseph at caviumnetworks.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>;
> Murthy NSSR <nidadavolu.murthy at caviumnetworks.com>; Jerin Jacob
> <jerin.jacob at caviumnetworks.com>; Narayana Prasad
> <narayanaprasad.athreya at caviumnetworks.com>; Ankur Dwivedi
> <ankur.dwivedi at caviumnetworks.com>; Nithin Dabilpuram
> <nithin.dabilpuram at caviumnetworks.com>; Ragothaman Jayaraman
> <rjayaraman at caviumnetworks.com>; Srisivasubramanian S <ssrinivasan at caviumnetworks.com>;
> Tejasree Kondoj <kondoj.tejasree at caviumnetworks.com>
> Subject: Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities
> 
> 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. As
> > 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?
> 
> I think we should avoid adding some code in a .h file.
> And it is even worst when using macros.
> 
> 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.
> 
I can't remember all the variations we tried, but there were a few.
I think the macro works well in this case. 
What is the issue we need to solve?



More information about the dev mailing list