On Tue, May 12, 2020 at 11:31:26AM +0200, David Marchand wrote: > External Email > > ---------------------------------------------------------------------- > On Sat, Apr 11, 2020 at 4:16 PM <jer...@marvell.com> wrote: > > > > From: Nithin Dabilpuram <ndabilpu...@marvell.com> > > > > Add arm64 specific IPv4 lookup process function > > for ip4_lookup node. This node performs LPM lookup > > on every packet received and forwards it to a next > > node that is identified by lookup result. > > > > Signed-off-by: Nithin Dabilpuram <ndabilpu...@marvell.com> > > Signed-off-by: Kiran Kumar K <kirankum...@marvell.com> > > Signed-off-by: Pavan Nikhilesh <pbhagavat...@marvell.com> > > --- > > lib/librte_node/ip4_lookup.c | 6 + > > lib/librte_node/ip4_lookup_neon.h | 238 ++++++++++++++++++++++++++++++ > > 2 files changed, 244 insertions(+) > > create mode 100644 lib/librte_node/ip4_lookup_neon.h > > Checking OVS dpdk-latest branch, I caught a build issue on Ubuntu > 16.04 for aarch64. > I reproduced it in travis by forcing the distribution to xenial in > .travis.yml. > > FAILED: gcc -Ilib/lib@@rte_node@sta -Ilib -I../lib -Ilib/librte_node > -I../lib/librte_node -I. -I../ -Iconfig -I../config > -Ilib/librte_eal/include -I../lib/librte_eal/include > -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include > -Ilib/librte_eal/arm/include -I../lib/librte_eal/arm/include > -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal > -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs > -Ilib/librte_telemetry/../librte_metrics > -I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry > -I../lib/librte_telemetry -Ilib/librte_graph -I../lib/librte_graph > -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool > -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring > -Ilib/librte_lpm -I../lib/librte_lpm -Ilib/librte_hash > -I../lib/librte_hash -Ilib/librte_ethdev -I../lib/librte_ethdev > -Ilib/librte_net -I../lib/librte_net -Ilib/librte_meter > -I../lib/librte_meter -Ilib/librte_cryptodev -I../lib/librte_cryptodev > -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall > -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual > -Wdeprecated -Wformat-nonliteral -Wformat-security > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > -Wold-style-definition -Wpointer-arith -Wsign-compare > -Wstrict-prototypes -Wundef -Wwrite-strings > -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC > -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -fno-strict-aliasing > -MD -MQ 'lib/lib@@rte_node@sta/librte_node_ip4_lookup.c.o' -MF > 'lib/lib@@rte_node@sta/librte_node_ip4_lookup.c.o.d' -o > 'lib/lib@@rte_node@sta/librte_node_ip4_lookup.c.o' -c > ../lib/librte_node/ip4_lookup.c > In file included from ../lib/librte_node/ip4_lookup.c:34:0: > ../lib/librte_node/ip4_lookup_neon.h: In function ‘ip4_lookup_node_process’: > ../lib/librte_node/ip4_lookup_neon.h:25:12: error: ‘dip’ may be used > uninitialized in this function [-Werror=maybe-uninitialized] > int32x4_t dip; > ^ > cc1: all warnings being treated as errors > ninja: build stopped: subcommand failed. > > > The odd thing is that a more recent gcc does not complain. > So there must be a catch, can you have a look? > Thanks. >
Sure. Thanks. Will test and get back. > > -- > David Marchand >
