[dpdk-dev] [PATCH v8 2/4] meson: add infra to support machine specific flags

[Yongseok Koh]

> On Apr 11, 2019, at 11:43 PM, Yongseok Koh <yskoh at mellanox.com> wrote:
> 
> 
>> On Apr 11, 2019, at 11:07 PM, Jerin Jacob Kollanukkaran <jerinj at marvell.com> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Yongseok Koh <yskoh at mellanox.com>
>>> Sent: Friday, April 12, 2019 7:35 AM
>>> To: Pavan Nikhilesh Bhagavatula <pbhagavatula at marvell.com>
>>> Cc: Thomas Monjalon <thomas at monjalon.net>; dev <dev at dpdk.org>; Jerin
>>> Jacob Kollanukkaran <jerinj at marvell.com>; jerinjacobk at gmail.com
>>> Subject: [EXT] Re: [dpdk-dev] [PATCH v8 2/4] meson: add infra to support
>>> machine specific flags
>>> 
>>> External Email
>>> 
>>> I've tested it but still have an issue with old gcc.
>>> Even if -mcpu isn't set due to cc.has_argument(), -march isn't set either.
>>> So, it spews error due to lack of CRC feature.
>>> -march should have '+crc'. The error I got was:
>>> 
>>>> ninja: Entering directory `build'
>>>> [942/1452] Compiling C object
>>> 'drivers/drivers...c at sta/net_softnic_rte_eth_softnic_action.c.o'.
>>>> FAILED:
>>>> 
>>> drivers/drivers@@tmp_rte_pmd_softnic at sta/net_softnic_rte_eth_softnic
>>> _a
>>>> ction.c.o cc -Idrivers/drivers@@tmp_rte_pmd_softnic at sta -Idrivers
>>>> -I../drivers -Idrivers/net/softnic -I../drivers/net/softnic
>>>> -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I../ -Iconfig
>>>> -I../config-Ilib/librte_eal/common/include
>>>> -I../lib/librte_eal/common/include
>>>> -I../lib/librte_eal/linux/eal/include -Ilib/librte_eal/common
>>>> -I../lib/librte_eal/common -Ilib/librte_eal/ common/include/arch/arm
>>>> -I../lib/librte_eal/common/include/arch/arm -Ilib/librte_eal
>>>> -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs
>>>> -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf
>>>> -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool
>>>> -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_cmdline
>>>> -I../lib/librte_cmdline -Ilib/lib rte_meter -I../lib/librte_meter
>>>> -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux
>>>> -Ilib/librte_pci -I../lib/librte_pci -Idrivers/bus/vdev
>>>> -I../drivers/bus/vdev -Ilib/librte_pipeline -I../lib/librte_pipeline
>>>> -Ilib/librte_port -I../lib/librte_port -Ilib/librte_sched
>>>> -I../lib/librte_sched -Ilib/librte_ip_frag -I../lib/librte_ip_frag
>>>> -Ilib/librte_h ash -I../lib/librte_hash -Ilib/librte_cryptodev
>>>> -I../lib/librte_cryptodev -Ilib/librte_kni -I../lib/librte_kni
>>>> -Ilib/librte_table -I../lib/librte_table -Ilib/librte_lpm
>>>> -I../lib/librte_lpm -Ilib/librte_acl -I../lib/librte_acl -pipe
>>>> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h
>>>> -Wsign-compare -Wcast-qual -fPIC -D_GNU_SOURCE -DALLOW_EXPERI
>>>> MENTAL_API  -MD -MQ
>>>> 
>>> 'drivers/drivers@@tmp_rte_pmd_softnic at sta/net_softnic_rte_eth_softnic
>>> _
>>>> action.c.o' -MF
>>>> 
>>> 'drivers/drivers@@tmp_rte_pmd_softnic at sta/net_softnic_rte_eth_softnic
>>> _
>>>> action.c.o.d' -o
>>>> 
>>> 'drivers/drivers@@tmp_rte_pmd_softnic at sta/net_softnic_rte_eth_softnic
>>> _
>>>> action.c.o' -c ../drivers/net/softnic/rte_eth_softnic_action.c
>>>> {standard input}: Assembler messages:
>>>> {standard input}:14: Error: selected processor does not support `crc32cx
>>> w3,w3,x0'
>>>> {standard input}:37: Error: selected processor does not support `crc32cx
>>> w1,w1,x3'
>>>> {standard input}:40: Error: selected processor does not support `crc32cx
>>> w0,w0,x2'
>>> 
>>> 
>>> My machine has 0x41(Arm) and 0xd08(cortex-a72). gcc is '4.8.5 20150623 (Red
>>> Hat 4.8.5-28)'
>> 
>> Are you testing with very latest master where the following patch available in build?
>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F52367%2F&data=02%7C01%7Cyskoh%40mellanox.com%7C5909260f30a64e07a95108d6bf123bde%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636906482386596820&sdata=4%2BfRfELXK37SNY4wdFNGPF8lpU7S3DEfPoDfAH5K7GE%3D&reserved=0
>> It should fix that issue.
> 
> Thanks, that fixes the issue.
> But I've encountered another one. Are you aware of this?
> 
> ninja: Entering directory `build'
> [1151/1452] Compiling C object 'drivers/drivers@@tmp_r...d_octeontx_event at sta/event_octeontx_timvf_worker.c.o'.
> FAILED: drivers/drivers@@tmp_rte_pmd_octeontx_event at sta/event_octeontx_timvf_worker.c.o
> cc -Idrivers/drivers@@tmp_rte_pmd_octeontx_event at sta -Idrivers -I../drivers -Idrivers/event/octeontx -I../drivers/event/octeontx -Ilib/librte_eventdev -I../lib/librte_eventdev -I. -I../ -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/linux/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/arm -I../lib/librte_eal/co
> mmon/include/arch/arm -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_ethdev -I../lib/librte_ethdev -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_cmdline -I../lib/librte_cmdline -Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_hash -I../lib/librte_h
> ash -Ilib/librte_timer -I../lib/librte_timer -Ilib/librte_cryptodev -I../lib/librte_cryptodev -Idrivers/common/octeontx -I../drivers/common/octeontx -Idrivers/mempool/octeontx -I../drivers/mempool/octeontx -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci -Idrivers/bus/vdev -I../drivers/bus/vdev -Idrivers/net/octeontx -I../drivers/net/octeontx -Idrivers/net/octeontx/base
> -I../drivers/net/octeontx/base -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h -Wsign-compare -Wcast-qual -fPIC -D_GNU_SOURCE -DALLOW_EXPERIMENTAL_API  -MD -MQ 'drivers/drivers@@tmp_rte_pmd_octeontx_event at sta/event_octeontx_timvf_worker.c.o' -MF 'drivers/drivers@@tmp_rte_pmd_octeontx_event at sta/event_octeontx_timvf_worker.c.o.d' -o 'drivers/drivers@@tmp_rte_pmd_octeontx_event at sta/event_octeontx_t
> imvf_worker.c.o' -c ../drivers/event/octeontx/timvf_worker.c
> ../drivers/event/octeontx/timvf_worker.c: In function ‘timvf_timer_arm_burst_sp’:
> ../drivers/event/octeontx/timvf_worker.c:88:1: error: could not split insn
> }
> ^
> (insn 95 98 99 (parallel [
>            (set (reg:DI 3 x3 [orig:98 D.8656 ] [98])
>                (mem/v:DI (reg/f:DI 21 x21 [orig:88 D.8662 ] [88]) [-1  S8 A64]))
>            (set (mem/v:DI (reg/f:DI 21 x21 [orig:88 D.8662 ] [88]) [-1  S8 A64])
>                (unspec_volatile:DI [
>                        (plus:DI (mem/v:DI (reg/f:DI 21 x21 [orig:88 D.8662 ] [88]) [-1  S8 A64])
>                            (const_int -281474976710656 [0xffff000000000000]))
>                        (const_int 0 [0])
>                    ] UNSPECV_ATOMIC_OP))
>            (clobber (reg:CC 66 cc))
>            (clobber (reg:DI 0 x0))
>            (clobber (reg:SI 1 x1))
>        ]) ../drivers/event/octeontx/timvf_worker.h:95 1832 {atomic_fetch_adddi}
>     (expr_list:REG_UNUSED (reg:CC 66 cc)
>        (expr_list:REG_UNUSED (reg:SI 1 x1)
>            (expr_list:REG_UNUSED (reg:DI 0 x0)
>                (nil)))))
> ../drivers/event/octeontx/timvf_worker.c:88:1: internal compiler error: in final_scan_insn, at final.c:2897
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbugzilla.redhat.com%2Fbugzilla&data=02%7C01%7Cyskoh%40mellanox.com%7C5909260f30a64e07a95108d6bf123bde%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636906482386596820&sdata=2AH1gInkxui7UEDb7LLNppMxDEaf%2F5N5TEHhDRTSDJY%3D&reserved=0> for instructions.
> {standard input}: Assembler messages:
> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
> Preprocessed source stored into /tmp/ccnQRbOm.out file, please attach this to your bugreport.
> [1168/1452] Compiling C object 'drivers/drivers@@tmp_r...ntx_crypto at sta/crypto_octeontx_otx_cryptodev_ops.c.o'.
> ninja: build stopped: subcommand failed.


One more issue.
With gcc7.2, crypto isn't enabled if -mcpu is set.
How about thunderx/octeon?
Looks it should be like -mcpu=cortex-a72+crypto
I'll take care of this in a separate patch.
Because I want to add a new option to control it.
The reason is a binary having crypto support can't be run on a cpu w/o crypto extension, it is panicked.
And -mcpu=cortex-a72 includes 'crc' support by default.


Thanks,
Yongseok