[dpdk-dev] [PATCH v4 03/41] bus/dpaa: add compatibility and helper macros

Shreyansh Jain shreyansh.jain at nxp.com
Tue Sep 26 14:43:55 CEST 2017


On Tuesday 19 September 2017 07:27 PM, Shreyansh Jain wrote:
> On Tuesday 19 September 2017 07:10 PM, Ferruh Yigit wrote:
>> On 9/19/2017 2:18 PM, Shreyansh Jain wrote:
>>> On Monday 18 September 2017 08:19 PM, Ferruh Yigit wrote:
>>>> On 9/9/2017 12:20 PM, Shreyansh Jain wrote:
>>>>> From: Hemant Agrawal <hemant.agrawal at nxp.com>
>>>>>
>>>>> Linked list, bit operations and compatibility macros.
>>>>>
>>>>> Signed-off-by: Geoff Thorpe <geoff.thorpe at nxp.com>
>>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
>>>>

[...]

>>>>> + */
>>>>
>>
>> <...>
>>
>>>>> +
>>>>> +#ifndef __DPAA_LIST_H
>>>>> +#define __DPAA_LIST_H
>>>>> +
>>>>> +/****************/
>>>>> +/* Linked-lists */
>>>>> +/****************/
>>>>
>>>> Do we need to maintain a linked list implementation, why no just use
>>>> sys/queue.h ones as done many places in DPDK?
>>>>
>>>>> +
>>>>> +struct list_head {
>>>>> +    struct list_head *prev;
>>>>> +    struct list_head *next;
>>>>> +};
>>>>> +
>>>>
>>>> <...>
>>>>
>>>
>>> The underlying DPAA infrastructure code is shared between kernel and
>>> userspace. That is why, changing the internal headers (for example,
>>> using RTE_* queues) is something I want to avoid until absolutely
>>> necessary. The outer layers (drivers/*/dpaa/<here>) are something I am
>>> trying to keep as close to possible to DPDK.
>>
>> I understand you want to escape from maintaining a copy of common files
>> for DPDK, this has been done by many drivers, as not changing "base"
>> files, this makes sense.
>>
>> But for this case, file is "dpaa_list.h" and as far as I can see all it
>> has is linked list implementation, this looked easy to exclude, but if
>> not you can ignore the comment.
> 
> Got your point. I will respin and see how much is the impact.
> Thanks for inputs.

I tried to work around the dpaa_list.h use in DPAA code - but, the 
changes are subtle but large in number - though, restricted only to base 
framework.
I would prefer to skip this for a while as the driver is stable now. I 
would probably do this change in a incremental manner to keep it traceable.

Ferruh, Is that OK with you?



More information about the dev mailing list