[dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[Damjan Marion (damarion)]

Folks,

I have issues with linking application to 16.07-rc2.

Looks like reason is constructor function in include file,
so our unit test apps are failing to link as they are not linked with dpdk libs.
(and they should not be as they are not calling any dpdk function).


static inline void __attribute__((constructor))
rte_rtm_init(void)
{
        rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
}

linking fails with:
dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled’

Is there any chance that this one is moved to some .c file, so it is loaded
only when it is really needed?

Thanks,

Damjan

Re: [dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[Thomas Monjalon]

2016-07-13 22:58, Damjan Marion:
> I have issues with linking application to 16.07-rc2.
> 
> Looks like reason is constructor function in include file,
> so our unit test apps are failing to link as they are not linked with dpdk libs.
> (and they should not be as they are not calling any dpdk function).

I don't understand:
Why are you linking DPDK if you do not use any DPDK function?

> static inline void __attribute__((constructor))
> rte_rtm_init(void)
> {
>         rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
> }
> 
> linking fails with:
> dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled’
> 
> Is there any chance that this one is moved to some .c file, so it is loaded
> only when it is really needed?

Yes it could be moved to lib/librte_eal/common/arch/x86/.

Re: [dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[Damjan Marion (damarion)]

> On 14 Jul 2016, at 10:20, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 
> 2016-07-13 22:58, Damjan Marion:
>> I have issues with linking application to 16.07-rc2.
>> 
>> Looks like reason is constructor function in include file,
>> so our unit test apps are failing to link as they are not linked with dpdk libs.
>> (and they should not be as they are not calling any dpdk function).
> 
> I don't understand:
> Why are you linking DPDK if you do not use any DPDK function?

If i simplify it, i have 4 components:

1. libdpdk
2. libXXX
3. app-A
4. app-B

libXXX includes some dpdk headers, mainly because of data structures like rte_mbuf, and some functions are calling
functions form libdpdk.

app-A links against libdpdk and libXXX
app-B links against libXXX only and only uses functions from libXXX which doesn’t have dpdk dependency

This is working fine in 14.04. In 14.07 rte_rtm_init() implants himself into libXXX as it is defined
in header file, and that causes linking to fail due to missing rte_cpu_get_flag_enabled().

> 
>> static inline void __attribute__((constructor))
>> rte_rtm_init(void)
>> {
>>        rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
>> }
>> 
>> linking fails with:
>> dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled’
>> 
>> Is there any chance that this one is moved to some .c file, so it is loaded
>> only when it is really needed?
> 
> Yes it could be moved to lib/librte_eal/common/arch/x86/.


Any chance to get this in 16.07 ?

Thanks!

Re: [dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[Thomas Monjalon]

2016-07-14 09:36, Damjan Marion:
> 
> > On 14 Jul 2016, at 10:20, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > 
> > 2016-07-13 22:58, Damjan Marion:
> >> I have issues with linking application to 16.07-rc2.
> >> 
> >> Looks like reason is constructor function in include file,
> >> so our unit test apps are failing to link as they are not linked with dpdk libs.
> >> (and they should not be as they are not calling any dpdk function).
> > 
> > I don't understand:
> > Why are you linking DPDK if you do not use any DPDK function?
> 
> If i simplify it, i have 4 components:
> 
> 1. libdpdk
> 2. libXXX
> 3. app-A
> 4. app-B
> 
> libXXX includes some dpdk headers, mainly because of data structures like rte_mbuf, and some functions are calling
> functions form libdpdk.
> 
> app-A links against libdpdk and libXXX
> app-B links against libXXX only and only uses functions from libXXX which doesn’t have dpdk dependency
> 
> This is working fine in 14.04. In 14.07 rte_rtm_init() implants himself into libXXX as it is defined
> in header file, and that causes linking to fail due to missing rte_cpu_get_flag_enabled().

OK I better understand :)

> >> static inline void __attribute__((constructor))
> >> rte_rtm_init(void)
> >> {
> >>        rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
> >> }
> >> 
> >> linking fails with:
> >> dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled’
> >> 
> >> Is there any chance that this one is moved to some .c file, so it is loaded
> >> only when it is really needed?
> > 
> > Yes it could be moved to lib/librte_eal/common/arch/x86/.
> 
> Any chance to get this in 16.07 ?

Yes maybe if you submit a patch quickly and it is clean enough.

Re: [dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

[Damjan Marion (damarion)]

> On 14 Jul 2016, at 13:30, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 
> 2016-07-14 09:36, Damjan Marion:
>>>> 
>>>> linking fails with:
>>>> dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled’
>>>> 
>>>> Is there any chance that this one is moved to some .c file, so it is loaded
>>>> only when it is really needed?
>>> 
>>> Yes it could be moved to lib/librte_eal/common/arch/x86/.
>> 
>> Any chance to get this in 16.07 ?
> 
> Yes maybe if you submit a patch quickly and it is clean enough.

OK, I already have working patch[1], but it is possibly not clean enough.
Basically I moved rte_rtm_init to lib/librte_eal/common/arch/x86/rte_cpuflags.c

Is this the right place?

Should we call “rtm_supported” different, knowing that now it is not static anymore?

Thanks,

Damjan


[1] https://github.com/vpp-dev/vpp/blob/dpdk-16.07-rc2/dpdk/dpdk-16.07-rc2_patches/0001-Fix-linking-issue-due-to-constructor-in-header-file.patch