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

Joseph, Anoob Anoob.Joseph at caviumnetworks.com
Wed Oct 10 07:39:43 CEST 2018


Hi Fiona,

We were following the QAT approach for defining the capabilities. OCTEON 
TX crypto PMD has similar number of capabilities and QAT was the close 
model that we could follow. I can see the advantages of the macro 
approach, but that would give a checkpatch warning. Also, Thomas didn't 
really like the idea of having long macros. So we have fixed it in the 
upstream code.

I would like to understand what would be your approach when you add 
asymmetric support. We are also adding asymmetric support and would like 
to understand how you would be adding, while supporting devices with 
varying capability.

Thanks,
Anoob
On 09-10-2018 01:57, Thomas Monjalon wrote:
> External Email
>
> 08/10/2018 17:59, Trahe, Fiona:
>> Hi Akhil, Joseph, Thomas,
>> Just spotted this now.
>> See below.
>>
>> From: Thomas Monjalon [mailto:thomas at monjalon.net]
>>> 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?
> It is a discussion about best practice.
> My answer is: avoid long macros and avoid instructions in .h file.
>
>
>



More information about the dev mailing list