[dpdk-stable] [dpdk-dev] [PATCH] net/dpaa2: fix build error about timesync functions

Hemant Agrawal hemant.agrawal at oss.nxp.com
Thu Sep 17 17:40:00 CEST 2020


On 9/17/2020 5:29 PM, Ferruh Yigit wrote:
> On 9/17/2020 12:50 PM, Hemant Agrawal wrote:
>>
>> On 9/17/2020 5:08 PM, Ferruh Yigit wrote:
>>> On 9/17/2020 3:03 AM, Di, ChenxuX wrote:
>>>> Hi,
>>>>
>>>>> -----Original Message-----
>>>>> From: Ferruh Yigit <ferruh.yigit at intel.com>
>>>>> Sent: Wednesday, September 16, 2020 11:29 PM
>>>>> To: Di, ChenxuX <chenxux.di at intel.com>; hemant.agrawal at nxp.com
>>>>> Cc: sachin.saxena at nxp.com; stable at dpdk.org; dev at dpdk.org; Richardson,
>>>>> Bruce <bruce.richardson at intel.com>
>>>>> Subject: Re: [dpdk-stable] [PATCH] net/dpaa2: fix build error 
>>>>> about timesync
>>>>> functions
>>>>>
>>>>> On 9/15/2020 3:40 AM, Chenxu Di wrote:
>>>>>> When the build option has '-DRTE_LIBRTE_IEEE1588=1', the announce of
>>>>>> timesync functions will be build.
>>>>>> However the dpdk_conf doesn't hav RTE_LIBRTE_IEEE1588 so that the 
>>>>>> file
>>>>>> dpaa2_ptp.c will not be build.
>>>>>> It cause the build error.
>>>>>> This patch fixes it by adding set for dpdk_conf.
>>>>>>
>>>>>> Fixes: 184c39d16568 ("net/dpaa2: add DPRTC sub-module")
>>>>>> Cc: stable at dpdk.org
>>>>>>
>>>>>> Signed-off-by: Chenxu Di <chenxux.di at intel.com>
>>>>>> ---
>>>>>>    drivers/net/dpaa2/meson.build | 4 ++++
>>>>>>    1 file changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/dpaa2/meson.build
>>>>>> b/drivers/net/dpaa2/meson.build index 6dd0eb274..d9aadfdae 100644
>>>>>> --- a/drivers/net/dpaa2/meson.build
>>>>>> +++ b/drivers/net/dpaa2/meson.build
>>>>>> @@ -17,6 +17,10 @@ sources = files('base/dpaa2_hw_dpni.c',
>>>>>>            'mc/dpdmux.c',
>>>>>>            'mc/dpni.c')
>>>>>>
>>>>>> +if '-DRTE_LIBRTE_IEEE1588=1' in get_option('c_args')
>>>>>
>>>>> The "RTE_LIBRTE_IEEE1588=1" can fail,
>>>>> all places looking for "#ifdef RTE_LIBRTE_IEEE1588", so a "-Dc_args=-
>>>>> DRTE_LIBRTE_IEEE1588" is more likely, but why not "-Dc_args=-
>>>>> DRTE_LIBRTE_IEEE1588=666"
>>>>>
>>>>
>>>> Yes, I will change it
>>>>
>>>>>> + dpdk_conf.set('RTE_LIBRTE_IEEE1588', 1) endif
>>>>>> +
>>>>>>    if dpdk_conf.has('RTE_LIBRTE_IEEE1588')
>>>>>>        sources += files('mc/dprtc.c')
>>>>>>        sources += files('dpaa2_ptp.c')
>>>>>>
>>>>>
>>>>> Can't we just remove the conditional build:
>>>>>
>>>>>    -if dpdk_conf.has('RTE_LIBRTE_IEEE1588')
>>>>>    -       sources += files('mc/dprtc.c')
>>>>>    -       sources += files('dpaa2_ptp.c')
>>>>>    -endif
>>>>>    +sources += files('mc/dprtc.c')
>>>>>    +sources += files('dpaa2_ptp.c')
>>>>
>>>> The announce of timesync functions are in the #define 
>>>> DRTE_LIBRTE_IEEE1588
>>>> While the define of the functions are in the file 'dpaa2_ptp.c'.
>>>> So they should be both build or not build by whether the build 
>>>> option -DRTE_LIBRTE_IEEE1588=1 or not.
>>>> So it seems not a good idea that remove the conditional.
>>>>
>>>
>>> timesyncs_* dev_ops functions defined but not used is not big 
>>> problem, only can increase the library size.
>>>
>>> I believe more concern is on:
>>> 'RTE_PMD_REGISTER_DPAA2_OBJECT(dprtc, rte_dpaa2_dprtc_obj);'
>>> which looks like register function to run in constructor when 
>>> 'dpaa2_ptp.c' is compiled, but not sure affect of it.
>>> It can be possible to wrap that call with 'RTE_LIBRTE_IEEE1588' 
>>> ifdef, that should work.
>>>
>>> It is preferred to remove the compile time flag instead of finding 
>>> ways to make it work.
>>>
>>> Let's wait for the dpaa2 maintainers' response, perhaps they can 
>>> come with a smart way to remove the compile time flag.
>>
>> Hi Ferruh,
>>
>>     enabling  IEEE1588 causes some performance drop in the dpaa2 
>> performance. That is the reason, we have kept this code in compile 
>> time flag.
>>
>>
>> However, we will work in future to make it run-time configurable but 
>> that will require some code restructuring and it will be a moderate 
>> size work.
>>
>
> OK, thanks Hemant.
>
> At least can it be possible to remove it from the build files, what do 
> you think about wrapping those two files (or their relevant parts) 
> with 'RTE_LIBRTE_IEEE1588' ifdef and remove the checks from meson file?
>
ok.


More information about the stable mailing list