from:"Brian Brooks"

Re: [vpp-dev] VPP ARM Build/Installation

2018-07-02 Thread Brian Brooks

Hi Jit,

On AArch64 machine:

$ git clone https://gerrit.fd.io/r/vpp
$ cd vpp
$ make build-release

Packages in nexus (not exactly sure which one):
https://nexus.fd.io/#view-repositories;fd.io.master.ubuntu-arm.xenial.main~browsestorage

Brian

From: vpp-dev@lists.fd.io  On Behalf Of Jit Mehta
Sent: Friday, June 29, 2018 11:28 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP ARM Build/Installation

Hello,

Is there a way I can download and install aarch64 binaries?
If not, is there a wiki that lists how to build aarch64 targets?

Thanks,
Jit
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9761): https://lists.fd.io/g/vpp-dev/message/9761
Mute This Topic: https://lists.fd.io/mt/22895892/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] when is make test-all run?

2018-05-09 Thread Brian Brooks

Patch?
Nightly?
Release?

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9228): https://lists.fd.io/g/vpp-dev/message/9228
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/18967700
Mute This Topic: https://lists.fd.io/mt/18967700/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

<>

Re: [vpp-dev] vlib_main() taking maximum cycle in v1804 release

2018-05-09 Thread Brian Brooks

I think this is due to perf aggregating results from all CPUs, and that 
vlib_main hotspot is from the main (non-worker) thread.

From: vpp-dev@lists.fd.io  On Behalf Of Saxena, Nitin
Sent: Thursday, April 26, 2018 1:46 PM
To: vpp-dev 
Subject: [vpp-dev] vlib_main() taking maximum cycle in v1804 release

Hi,

While running L3 Fwd test case with VPP v1804 release (released yesterday), 
perf tool shows vlib_main() taking maximum cycles.
This has been observed on Aarch64 (Both on Marvell’s Macchiatobin and Cavium’s 
ThunderX products) and Broadwell machine as well.

Perf top from Broadwell machine
=
 29.72%  libvlib.so.0.0.0[.] vlib_main
  17.33%  dpdk_plugin.so  [.] i40e_xmit_pkts
   7.35%  dpdk_plugin.so  [.] i40e_recv_scattered_pkts_vec
   7.21%  libvlibmemory.so.0.0.0  [.] memclnt_queue_callback
   6.02%  libvnet.so.0.0.0[.] ip4_rewrite_avx2
   5.96%  libvnet.so.0.0.0[.] ip4_lookup_avx2
   5.69%  libvnet.so.0.0.0[.] ip4_input_no_checksum_avx2
   5.49%  dpdk_plugin.so  [.] dpdk_input_avx2
   3.40%  dpdk_plugin.so  [.] dpdk_interface_tx_avx2
   1.63%  libvnet.so.0.0.0[.] vnet_interface_output_node_avx2

Is this the expected behaviour? I haven’t observed vlib_main() taking max perf 
cycles in VPP v1801.

Thanks,
Nitin

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [vpp-dev] VPP with DPDK eventdev

2018-04-26 Thread Brian Brooks

Can eventdev inspire VPP to process packets from the same flow across multiple 
CPUs?

Brian

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion
Sent: Monday, April 23, 2018 11:29 AM
To: Andrew Pinski 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP with DPDK eventdev

I’m not aware of such activities, but before you start working on the actual 
implementation i would suggest community discussion on architecture, use cases 
and required changes in the code. Biweekly community call is likely good forum 
for that.

—
Damjan

> On 22 Apr 2018, at 07:17, Andrew Pinski  wrote:
>
> Hi all,
>  We were wondering if anyone is currently working on getting VPP to
> work with the DPDK eventdev?  We don't want to duplication.
>
> Thanks,
> Andrew
>
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9085): https://lists.fd.io/g/vpp-dev/message/9085
View All Messages In Topic (3): https://lists.fd.io/g/vpp-dev/topic/18050545
Mute This Topic: https://lists.fd.io/mt/18050545/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

2018-04-25 Thread Brian Brooks

Thanks, Ole.

Stanislav, does this help? Are you able to natively compile on arm64 instead of 
cross?

Brian

-Original Message-
From: Ole Troan 
Sent: Wednesday, April 25, 2018 11:56 AM
To: Brian Brooks 
Cc: Stanislav Chlebec ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Brian,

> This appears to be related to cross compiling VPP.
> vppapigen is built for the cross target, but then run on the host as part of 
> the build.
>
> Can someone who is familiar with the build system confirm? If so, is it worth 
> fixing a cross build such that vppapigen is compiled for host target and run 
> on host target when cross compiling for the cross target?


vppapigen has been replaced with a PLY based compiler. Which does not need to 
be built.
Would you be able to try with that?

https://gerrit.fd.io/r/#/c/8781/

Best regards,
Ole

> From: vpp-dev@lists.fd.io  On Behalf Of Brian
> Brooks
> Sent: Friday, April 20, 2018 5:18 PM
> To: Stanislav Chlebec ;
> vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu
> static library qemu-aarch64-static in Docker container
>
> Can you copy/paste the compiler or linker error?
>
> From: vpp-dev@lists.fd.io  On Behalf Of Stanislav
> Chlebec
> Sent: Friday, April 20, 2018 6:05 AM
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu
> static library qemu-aarch64-static in Docker container
>
> Hello Brian
> I have not yet tried to build it in the arm64 VM.
> What I found out more that build fails in the file src/vppinfra/time.h
> ...
> 
> #elif defined (__aarch64__)
> always_inline u64
> clib_cpu_time_now (void)
> {
>   u64 tsc;
>
>   /* Works on Cavium ThunderX. Other platforms: YMMV */
>   asm volatile ("mrs %0, cntvct_el0":"=r" (tsc));
>
>   return tsc;
> }
> ...
>
> Stanislav
>
>
> From: Brian Brooks [mailto:brian.bro...@arm.com]
> Sent: Monday, April 16, 2018 7:51 PM
> To: Stanislav Chlebec ;
> vpp-dev@lists.fd.io
> Subject: RE: Trying to build vpp on amd64 platform via qemu static
> library qemu-aarch64-static in Docker container
>
> Hi Stanislav,
>
> Does the build work if you git clone and make build-release inside the arm64 
> VM (no docker)?
>
> Brian
>
> From: vpp-dev@lists.fd.io  On Behalf Of Stanislav
> Chlebec
> Sent: Monday, April 16, 2018 2:27 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Trying to build vpp on amd64 platform via qemu
> static library qemu-aarch64-static in Docker container
>
> Hello all
> I am trying to prepare arm64 docker image (based on arm64v8/ubuntu:latest) in 
> which will be vpp compiled and installed.
> I  do it on amd64 platform using qemu static library for qemu-aarch64-static 
> for emulation of arm64 instructions.
>
> (
> I found how to do it here:
> https://blog.hypriot.com/post/setup-simple-ci-pipeline-for-arm-images/
> http://www.hotblackrobotics.com/en/blog/2018/01/22/docker-images-arm/
> )
>
> Everything goes more the less  well but it fails in this Dockerfile step:
> {
> RUN /bin/bash -c "\
> git clone https://github.com/vpp-dev/vpp.git \
> && cd vpp \
> && git checkout ${VPP_COMMIT} \
> && UNATTENDED=y make vpp_configure_args_vpp='--disable-japi 
> --disable-vom' install-dep bootstrap dpdk-install-dev build build-release;"
> }
>
> It seems that build of vpp is complete without errors but the next processes 
> (installing od dpdk ?) will end with error 21326 Illegal instruction:
> {
> ….
> Build complete [arm64-armv8a-linuxapp-gcc] ==
> Installing /opt/vpp-agent/dev/vpp/dpdk/deb/debian/tmp/usr/
> ….
> ….
> ==
>   version vpp 18.01
>   prefix  
> /opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp
>   libdir  
> /opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp/lib64
>   includedir  ${prefix}/include
>   CFLAGS   -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
> -fstack-protector-all -fPIC -Werror
>   CPPFLAGS  
> -I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/include/dpdk
>  -I/usr/include/dpdk
>   LDFLAGS  -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
> -fstack-protector-all -fPIC -Werror   
> -L/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib 
> -Wl,-rpath 
> -Wl,/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib
>
> with:
>   libssl  yes

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

2018-04-25 Thread Brian Brooks

This appears to be related to cross compiling VPP.
vppapigen is built for the cross target, but then run on the host as part of 
the build.

Can someone who is familiar with the build system confirm? If so, is it worth 
fixing a cross build such that vppapigen is compiled for host target and run on 
host target when cross compiling for the cross target?

BB

From: vpp-dev@lists.fd.io  On Behalf Of Brian Brooks
Sent: Friday, April 20, 2018 5:18 PM
To: Stanislav Chlebec ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Can you copy/paste the compiler or linker error?

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Stanislav Chlebec
Sent: Friday, April 20, 2018 6:05 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Hello Brian
I have not yet tried to build it in the arm64 VM.
What I found out more that build fails in the file src/vppinfra/time.h
...

#elif defined (__aarch64__)
always_inline u64
clib_cpu_time_now (void)
{
  u64 tsc;

  /* Works on Cavium ThunderX. Other platforms: YMMV */
  asm volatile ("mrs %0, cntvct_el0":"=r" (tsc));

  return tsc;
}
...

Stanislav


From: Brian Brooks [mailto:brian.bro...@arm.com]
Sent: Monday, April 16, 2018 7:51 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: Trying to build vpp on amd64 platform via qemu static library 
qemu-aarch64-static in Docker container

Hi Stanislav,

Does the build work if you git clone and make build-release inside the arm64 VM 
(no docker)?

Brian

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Stanislav Chlebec
Sent: Monday, April 16, 2018 2:27 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Hello all
I am trying to prepare arm64 docker image (based on arm64v8/ubuntu:latest) in 
which will be vpp compiled and installed.
I  do it on amd64 platform using qemu static library for qemu-aarch64-static 
for emulation of arm64 instructions.

(
I found how to do it here:
https://blog.hypriot.com/post/setup-simple-ci-pipeline-for-arm-images/
http://www.hotblackrobotics.com/en/blog/2018/01/22/docker-images-arm/
)

Everything goes more the less  well but it fails in this Dockerfile step:
{
RUN /bin/bash -c "\
git clone https://github.com/vpp-dev/vpp.git \
&& cd vpp \
&& git checkout ${VPP_COMMIT} \
&& UNATTENDED=y make vpp_configure_args_vpp='--disable-japi --disable-vom' 
install-dep bootstrap dpdk-install-dev build build-release;"
}

It seems that build of vpp is complete without errors but the next processes 
(installing od dpdk ?) will end with error 21326 Illegal instruction:
{

Build complete [arm64-armv8a-linuxapp-gcc]
== Installing /opt/vpp-agent/dev/vpp/dpdk/deb/debian/tmp/usr/


==
  version vpp 18.01
  prefix  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp
  libdir  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp/lib64
  includedir  ${prefix}/include
  CFLAGS   -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror
  CPPFLAGS  
-I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/include/dpdk 
-I/usr/include/dpdk
  LDFLAGS  -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror   
-L/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib 
-Wl,-rpath 
-Wl,/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib

with:
  libssl  yes
.
==
 Building vpp in 
/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp 
make[2]: Entering directory 
'/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp'
  YACC tools/vppapigen/gram.c
  CC   vppinfra/socket.lo
  CC   vppinfra/timer.lo
  CC   vppinfra/unix-formats.lo
  CC   vppinfra/unix-misc.lo
  VERSION  vpp/app/version.h (18.01-rc0~374-g2d36ed2)
  CC   tools/vppapigen/lex.o
  CC   tools/vppapigen/gram.o
  CC   tools/vppapigen/node.o
  CC   vppinfra/asm_x86.lo
 CC   vppinfra/backtrace.lo
  CC   vppinfra/cpu.lo
  CC   vppinfra/elf.lo
  CC   vppinfra/elog.lo
  CC   vppinfra/error.lo
  CC   vppinfra/fifo.lo
  CC   vppinfra/fheap.

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

2018-04-20 Thread Brian Brooks

Can you copy/paste the compiler or linker error?

From: vpp-dev@lists.fd.io  On Behalf Of Stanislav Chlebec
Sent: Friday, April 20, 2018 6:05 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Hello Brian
I have not yet tried to build it in the arm64 VM.
What I found out more that build fails in the file src/vppinfra/time.h
...

#elif defined (__aarch64__)
always_inline u64
clib_cpu_time_now (void)
{
  u64 tsc;

  /* Works on Cavium ThunderX. Other platforms: YMMV */
  asm volatile ("mrs %0, cntvct_el0":"=r" (tsc));

  return tsc;
}
...

Stanislav

From: Brian Brooks [mailto:brian.bro...@arm.com]
Sent: Monday, April 16, 2018 7:51 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: Trying to build vpp on amd64 platform via qemu static library 
qemu-aarch64-static in Docker container

Hi Stanislav,

Does the build work if you git clone and make build-release inside the arm64 VM 
(no docker)?

Brian

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Stanislav Chlebec
Sent: Monday, April 16, 2018 2:27 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Hello all
I am trying to prepare arm64 docker image (based on arm64v8/ubuntu:latest) in 
which will be vpp compiled and installed.
I  do it on amd64 platform using qemu static library for qemu-aarch64-static 
for emulation of arm64 instructions.

(
I found how to do it here:
https://blog.hypriot.com/post/setup-simple-ci-pipeline-for-arm-images/
http://www.hotblackrobotics.com/en/blog/2018/01/22/docker-images-arm/
)

Everything goes more the less  well but it fails in this Dockerfile step:
{
RUN /bin/bash -c "\
git clone https://github.com/vpp-dev/vpp.git \
&& cd vpp \
&& git checkout ${VPP_COMMIT} \
&& UNATTENDED=y make vpp_configure_args_vpp='--disable-japi --disable-vom' 
install-dep bootstrap dpdk-install-dev build build-release;"
}

It seems that build of vpp is complete without errors but the next processes 
(installing od dpdk ?) will end with error 21326 Illegal instruction:
{

Build complete [arm64-armv8a-linuxapp-gcc]
== Installing /opt/vpp-agent/dev/vpp/dpdk/deb/debian/tmp/usr/

==
  version vpp 18.01
  prefix  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp
  libdir  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp/lib64
  includedir  ${prefix}/include
  CFLAGS   -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror
  CPPFLAGS  
-I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/include/dpdk 
-I/usr/include/dpdk
  LDFLAGS  -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror   
-L/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib 
-Wl,-rpath 
-Wl,/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib

with:
  libssl  yes
.
==
 Building vpp in 
/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp 
make[2]: Entering directory 
'/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp'
  YACC tools/vppapigen/gram.c
  CC   vppinfra/socket.lo
  CC   vppinfra/timer.lo
  CC   vppinfra/unix-formats.lo
  CC   vppinfra/unix-misc.lo
  VERSION  vpp/app/version.h (18.01-rc0~374-g2d36ed2)
  CC   tools/vppapigen/lex.o
  CC   tools/vppapigen/gram.o
  CC   tools/vppapigen/node.o
  CC   vppinfra/asm_x86.lo
 CC   vppinfra/backtrace.lo
  CC   vppinfra/cpu.lo
  CC   vppinfra/elf.lo
  CC   vppinfra/elog.lo
  CC   vppinfra/error.lo
  CC   vppinfra/fifo.lo
  CC   vppinfra/fheap.lo
  CC   vppinfra/format.lo
  CC   vppinfra/pool.lo
  CC   vppinfra/graph.lo
  CC   vppinfra/hash.lo
  CC   vppinfra/heap.lo
  CPPASvppinfra/longjmp.lo
  CC   vppinfra/macros.lo
  CC   vppinfra/mhash.lo
  CC   vppinfra/mheap.lo
  CC   vppinfra/md5.lo
  CC   vppinfra/mem_mheap.lo
  CC   vppinfra/ptclosure.lo
  CC   vppinfra/random.lo
  CC   vppinfra/random_buffer.lo
  CC   vppinfra/random_isaac.lo
  CC   vppinfra/serialize.lo
  CC   vppinfra/slist.lo
  CC   vppinfra/std-formats.lo
  CC   vppinfra/string.lo
  CC   vppinfra/time.lo
  CC   vppinfra/timing_wheel.lo
  CC   vppinfra/tw_timer_2t_1w_2048sl.lo
  CC   vppinfra/tw_timer_16t_2w

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

2018-04-16 Thread Brian Brooks

Hi Stanislav,

Does the build work if you git clone and make build-release inside the arm64 VM 
(no docker)?

Brian

From: vpp-dev@lists.fd.io  On Behalf Of Stanislav Chlebec
Sent: Monday, April 16, 2018 2:27 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Trying to build vpp on amd64 platform via qemu static 
library qemu-aarch64-static in Docker container

Hello all
I am trying to prepare arm64 docker image (based on arm64v8/ubuntu:latest) in 
which will be vpp compiled and installed.
I  do it on amd64 platform using qemu static library for qemu-aarch64-static 
for emulation of arm64 instructions.

(
I found how to do it here:
https://blog.hypriot.com/post/setup-simple-ci-pipeline-for-arm-images/
http://www.hotblackrobotics.com/en/blog/2018/01/22/docker-images-arm/
)

Everything goes more the less  well but it fails in this Dockerfile step:
{
RUN /bin/bash -c "\
git clone https://github.com/vpp-dev/vpp.git \
&& cd vpp \
&& git checkout ${VPP_COMMIT} \
&& UNATTENDED=y make vpp_configure_args_vpp='--disable-japi --disable-vom' 
install-dep bootstrap dpdk-install-dev build build-release;"
}

It seems that build of vpp is complete without errors but the next processes 
(installing od dpdk ?) will end with error 21326 Illegal instruction:
{

Build complete [arm64-armv8a-linuxapp-gcc]
== Installing /opt/vpp-agent/dev/vpp/dpdk/deb/debian/tmp/usr/


==
  version vpp 18.01
  prefix  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp
  libdir  
/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/vpp/lib64
  includedir  ${prefix}/include
  CFLAGS   -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror
  CPPFLAGS  
-I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/include/dpdk 
-I/usr/include/dpdk
  LDFLAGS  -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 
-fstack-protector-all -fPIC -Werror   
-L/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib 
-Wl,-rpath 
-Wl,/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/lib

with:
  libssl  yes
.
==
 Building vpp in 
/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp 
make[2]: Entering directory 
'/opt/vpp-agent/dev/vpp/build-root/build-vpp_debug-native/vpp'
  YACC tools/vppapigen/gram.c
  CC   vppinfra/socket.lo
  CC   vppinfra/timer.lo
  CC   vppinfra/unix-formats.lo
  CC   vppinfra/unix-misc.lo
  VERSION  vpp/app/version.h (18.01-rc0~374-g2d36ed2)
  CC   tools/vppapigen/lex.o
  CC   tools/vppapigen/gram.o
  CC   tools/vppapigen/node.o
  CC   vppinfra/asm_x86.lo
 CC   vppinfra/backtrace.lo
  CC   vppinfra/cpu.lo
  CC   vppinfra/elf.lo
  CC   vppinfra/elog.lo
  CC   vppinfra/error.lo
  CC   vppinfra/fifo.lo
  CC   vppinfra/fheap.lo
  CC   vppinfra/format.lo
  CC   vppinfra/pool.lo
  CC   vppinfra/graph.lo
  CC   vppinfra/hash.lo
  CC   vppinfra/heap.lo
  CPPASvppinfra/longjmp.lo
  CC   vppinfra/macros.lo
  CC   vppinfra/mhash.lo
  CC   vppinfra/mheap.lo
  CC   vppinfra/md5.lo
  CC   vppinfra/mem_mheap.lo
  CC   vppinfra/ptclosure.lo
  CC   vppinfra/random.lo
  CC   vppinfra/random_buffer.lo
  CC   vppinfra/random_isaac.lo
  CC   vppinfra/serialize.lo
  CC   vppinfra/slist.lo
  CC   vppinfra/std-formats.lo
  CC   vppinfra/string.lo
  CC   vppinfra/time.lo
  CC   vppinfra/timing_wheel.lo
  CC   vppinfra/tw_timer_2t_1w_2048sl.lo
  CC   vppinfra/tw_timer_16t_2w_512sl.lo
  CC   vppinfra/tw_timer_16t_1w_2048sl.lo
  CC   vppinfra/tw_timer_4t_3w_256sl.lo
  CC   vppinfra/tw_timer_1t_3w_1024sl_ov.lo
  CC   vppinfra/unformat.lo
  CC   vppinfra/vec.lo
  CC   vppinfra/vector.lo
  CC   vppinfra/zvec.lo
  CC   vppinfra/elf_clib.lo
  CC   vppinfra/linux/mem.lo
  CC   vppinfra/linux/sysfs.lo
  CCLD libvppinfra.la
  CCLD vppapigen
  APIGEN   vnet/interface.api.h
  JSON API vlibmemory/memclnt.api.json
  APIGEN   vlibmemory/memclnt.api.h
[91m/bin/bash: line 3: 21320 Donegcc 
-I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-native/dpdk/include/dpdk 
-I/usr/include/dpdk -E -P -C -x c 
/opt/vpp-agent/dev/vpp/build-data/../src/vlibmemory/memclnt.api
 21321 Illegal instruction (core dumped) | ./vppapigen --input - --json 
vlibmemory/memclnt.api.json > /dev/null
[0mMakefile:8717: recipe for target 'vlibmemory/memclnt.api.json' failed
[91mmake[2]: *** [vlibmemory/memclnt.api.json] Error 132
[0m[91mmake[2]: *** Waiting for unfinished jobs
[0m[91m/bin/bash: line 3: 21324 Donegcc 
-I/opt/vpp-agent/dev/vpp/build-root/install-vpp_debug-

Re: [vpp-dev] [Fwd: [dpdk-dev] DPDK 18.02 on ARM64 is broken]

2018-02-22 Thread Brian Brooks

On 02/22 15:35:06, Marco Varlese wrote:
> Please, see below...
> 
> Maybe we should go back to 17.11 as the default version for now (18.02 is 
> broken
> for arm64 - confirmed over #dpdk channel on IRC).
> 
> Alternatively, a workaround is to disable the DPAA stuff:
> CONFIG_RTE_LIBRTE_DPAA_BUS=n
> CONFIG_RTE_LIBRTE_DPAA_MEMPOOL=n
> CONFIG_RTE_LIBRTE_DPAA_PMD=n

Since there is a specialized dpaa2.mk platform build, would
it be possible to always disable unused DPDK platform config
for the native platform build and then re-enable certain DPDK
config for specialized platform builds like dpaa2.mk?

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8309): https://lists.fd.io/g/vpp-dev/message/8309
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/12439043
Mute This Topic: https://lists.fd.io/mt/12439043/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] aarch64 compilation break

2018-02-20 Thread Brian Brooks

On 02/20 21:26:40, Brian Brooks wrote:
> On 02/20 14:43:47, Gabriel Ganne wrote:
> > Hi Damjan, Brian,
> > 
> > Damjan, your commit https://gerrit.fd.io/r/c/10670 has an impact in
> > vnet_classify that overlaps with what I had written in
> > https://gerrit.fd.io/r/c/10476/
> 
> I see this handles u32x4_zero_byte_mask, but I also see breakage
> due to u16x8_is_all_zero. Is there another review for that one?

Here it is: https://gerrit.fd.io/r/#/c/10687/

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8292): https://lists.fd.io/g/vpp-dev/message/8292
View All Messages In Topic (3): https://lists.fd.io/g/vpp-dev/topic/12326622
Mute This Topic: https://lists.fd.io/mt/12326622/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] aarch64 compilation break

2018-02-20 Thread Brian Brooks

On 02/20 14:43:47, Gabriel Ganne wrote:
> Hi Damjan, Brian,
> 
> Damjan, your commit https://gerrit.fd.io/r/c/10670 has an impact in
> vnet_classify that overlaps with what I had written in
> https://gerrit.fd.io/r/c/10476/

I see this handles u32x4_zero_byte_mask, but I also see breakage
due to u16x8_is_all_zero. Is there another review for that one?

> However, without some changes in vector_neon.h it has the side effect to
> break aarch64 compilation.
> I've updated mine above yours.
> If you have the time, could you have a look at it please ?
> Thanks.
> 
> Brian, since this is a compilation issue, let's not wait for all the
> performance tests results to come back before merging.
> We'll fix things later if need be, right ? (the performances are most
> probably better anyway)
> I've remove the -2 I set after last meeting.

OK. We are getting closer to having arm64 builds in CI. :)

> Best regards,
> 
> -- 
> Gabriel Ganne

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8291): https://lists.fd.io/g/vpp-dev/message/8291
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/12326622
Mute This Topic: https://lists.fd.io/mt/12326622/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Vpp service not stopping on Arm64.

2018-02-16 Thread Brian Brooks

Hi Adarsh,

Trying to parse this output...

Have you tried running vpp from the workspace that it was built in
instead of dealing with systemd (for now)?

On 02/16 13:54:08,  via Lists.Fd.Io wrote:
> Hi,
> 
> Pls check i started the vpp and found the interfaces were not detected in vpp
> 
> so try to bind the pci with igb_uio driver and then tried to stop it but 
> unable to stop.
> 
> 
> Logs : csit@tg:~/vpp$ sudo service vpp status
> ● vpp.service - vector packet processing engine
>    Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: 
> enabled)
>    Active: active (running) since Fri 2018-02-16 21:02:12 CST; 2s ago
>   Process: 28300 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>   Process: 28348 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
> status=0/SUCCESS)
>   Process: 28344 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>  Main PID: 28352 (vpp_main)
>     Tasks: 4
>    Memory: 48.0M
>   CPU: 187ms
>    CGroup: /system.slice/vpp.service
>    └─28352 /usr/bin/vpp -c /etc/vpp/startup.conf

What does DPDK section in startup.conf look like?

> Feb 16 21:02:12 tg vnet[28352]: EAL: VFIO support initialized
> Feb 16 21:02:12 tg vpp[28352]: EAL:   Invalid NUMA socket, default to 0
> Feb 16 21:02:12 tg vnet[28352]: EAL:   Invalid NUMA socket, default to 0
> Feb 16 21:02:12 tg vnet[28352]: EAL: Cannot open 
> /sys/bus/pci/devices/:02:01.0/resource0: No such file or directory
> Feb 16 21:02:12 tg vpp[28352]: EAL: Cannot open 
> /sys/bus/pci/devices/:02:01.0/resource0: No such file or directory
> Feb 16 21:02:12 tg vpp[28352]: EAL: Requested device :02:01.0 cannot be 
> used
> Feb 16 21:02:12 tg vnet[28352]: EAL: Requested device :02:01.0 cannot be 
> used
> Feb 16 21:02:12 tg vnet[28352]: unix_physmem_region_iommu_register: ioctl 
> (VFIO_IOMMU_MAP_DMA): Invalid argument
> Feb 16 21:02:12 tg vnet[28352]: dpdk_ipsec_process:1007: not enough DPDK 
> crypto resources, default to OpenSSL
> Feb 16 21:02:12 tg vnet[28352]: dpdk_lib_init:221: DPDK drivers found no 
> ports...
> csit@tg:~/vpp$ sudo vppctl show int
>   Name   Idx   State  Counter  
> Count     
> local0    0    down  
> csit@tg:~/vpp$ sudo vppctl show pci
> Address  Sock VID:PID Link Speed   Driver  Product Name   
>  Vital Product Data
> :02:01.0  1af4:1000   unknown  uio_pci_generic
>      
> :03:01.0  1af4:1000   unknown  uio_pci_generic
>      
> :04:01.0  1af4:1000   unknown  uio_pci_generic
>      
> :05:01.0  1af4:1000   unknown  uio_pci_generic
>      
> :06:01.0  1af4:1000   unknown  uio_pci_generic
>      
> :07:01.0  1af4:1000   unknown  uio_pci_generic
>     
> 
> csit@tg:~/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools$ 
> csit@tg:~/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools$ sudo 
> ./dpdk-devbind.py --bind=igb_uio :02:01.0
> [sudo] password for csit: 
> Error: bind failed for :02:01.0 - Cannot bind to driver igb_uio
> Error: unbind failed for :02:01.0 - Cannot open 
> /sys/bus/pci/drivers//unbind
> csit@tg:~/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools$ sudo -i
> root@tg:~# cd 
> /home/csit/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools/
> root@tg:/home/csit/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools# 
> ./dpdk-devbind.py --bind=igb_uio :02:01.0
> Error: bind failed for :02:01.0 - Cannot bind to driver igb_uio
> root@tg:/home/csit/vpp/build-root/build-vpp-native/dpdk/dpdk-17.11/usertools# 
> 
> csit@tg:~/dpdk$ sudo service vpp status● vpp.service - vector packet 
> processing engine
>    Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: 
> enabled)
>    Active: active (running) since Fri 2018-02-16 21:02:12 CST; 23min ago
>   Process: 28300 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>   Process: 28348 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
> status=0/SUCCESS)
>   Process: 28344 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>  Main PID: 28352 (vpp_main)
>     Tasks: 4
>    Memory: 59.6M
>   CPU: 4.859s
>    CGroup: /system.slice/vpp.service
>    └─28352 /usr/bin/vpp -c /etc/vpp/startup.conf
> csit@tg:~/dpdk$ sudo service vpp stop
> 
> 
> 
> 
> 
> 
> ^C
> csit@tg:~/dpdk$ sudo service vpp stop
> 
> 
> 
> 
> ^C
> csit@tg:~/dpdk$ sudo service vpp status
> ● vpp.service - vector packet processing engine
>    Loaded: loaded (/lib/systemd/system/vpp.service; enabled;

Re: [vpp-dev] make test-all

2017-11-14 Thread Brian Brooks

It does not complete within 20 minutes on other machines.

> I don't think we should do scale tests as part of verification tests.

Agree


-Original Message-
From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) 
[mailto:ksek...@cisco.com]
Sent: Tuesday, November 14, 2017 2:47 AM
To: Ole Troan 
Cc: Dave Barach (dbarach) ; John Lo (loj) ; 
Pavel Kotucek -X (pkotucek - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; Brian Brooks 
Subject: Re: [vpp-dev] make test-all

It is ...

it takes ~10 seconds to create 1000 subifs on a beefy UCS and the case tries to 
create 10, so that would indicate a runtime of ~16minutes...

Quoting Ole Troan (2017-11-14 03:53:28)
> Klement,
>
> > I don't know what to tell you ... I was never a fan of getting the
> > API trace post test run and putting it into test log (which is the
> > cause of 25MB allocation in this case - it's the CLI output) - from
> > my POV this is duplicate information as every API call is already
> > logged in-place when it's executed... BUT I didn't saw any harm in
> > doing so (besides clutter) and since the "create bazillion
> > subinterfaces" test went in without me being part of review process, I 
> > wasn't aware of it...
>
> If this is in test_p2p_ethernet, let me take that out.
> I don't think we should do scale tests as part of verification tests.
> I do not like the path we're on with regards to test run time.
>
> Cheers,
> Ole
>
> > Quoting Dave Barach (dbarach) (2017-11-13 13:33:41)
> >> Try increasing the size of the shared-memory API segment. An allocation of 
> >> 25mb is failing. You might ask yourself how sane it is to generate that 
> >> much output.
> >>
> >> Thanks… Dave
> >>
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io
> >> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X
> >> (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> >> Sent: Monday, November 13, 2017 5:27 AM
> >> To: John Lo (loj) ; Pavel Kotucek -X (pkotucek -
> >> PANTHEON TECHNOLOGIES at Cisco) ;
> >> vpp-dev@lists.fd.io; Brian Brooks 
> >> Subject: Re: [vpp-dev] make test-all
> >>
> >> So it seems that vpp coredumps while dumping the API trace after
> >> creating all the interfaces...
> >>
> >> (gdb) bt
> >> #0  0x7f14f4b1e428 in __GI_raise (sig=sig@entry=6) at
> >> ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1  0x7f14f4b2002a in __GI_abort () at abort.c:89
> >> #2  0x00405d83 in os_panic () at
> >> /home/ksekera/vpp/build-data/../src/vpp/vnet/main.c:268
> >> #3  0x7f14f5fe5f86 in clib_mem_alloc_aligned_at_offset 
> >> (os_out_of_memory_on_failure=1, align_offset=0, align=1, size=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:105
> >> #4  clib_mem_alloc (size=25282098) at
> >> /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:114
> >> #5  vl_msg_api_alloc_internal (may_return_null=0, pool=, 
> >> nbytes=25282098)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:176
> >> #6  vl_msg_api_alloc (nbytes=nbytes@entry=25282082) at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:207
> >> #7  0x00411392 in vl_api_cli_inband_t_handler
> >> (mp=0x300e2a0c) at
> >> /home/ksekera/vpp/build-data/../src/vpp/api/api.c:223
> >> #8  0x7f14f5fdfa23 in vl_msg_api_handler_with_vm_node 
> >> (am=am@entry=0x7f14f620d460 , the_msg=the_msg@entry=0x300e2a0c,
> >>vm=vm@entry=0x7f14f5fd6260 ,
> >> node=node@entry=0x7f14b410e000) at
> >> /home/ksekera/vpp/build-data/../src/vlibapi/api_shared.c:508
> >> #9  0x7f14f5fef35f in memclnt_process (vm=0x7f14f5fd6260 
> >> , node=0x7f14b410e000, f=)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_vlib.c:970
> >>
> >> (gdb) p input
> >> $5 = {buffer = 0x7f14b56f6558 "dump
> >> /tmp/vpp-unittest-P2PEthernetAPI-qRwMY6/vpp_api_trace.test_p2p_subi
> >> f_creation_10k.log\n",  index = 18446744073709551615, buffer_marks
> >> = 0x7f14b592a240, fill_buffer = 0x0, fill_buffer_arg = 0x0}
> >>
> >> I'm pretty sure that the history of this mess was:
> >>
> >> 1.) the test was added first as enhanced
> >> 2.) automatic dump of api trace was added, but only tested against 'make 
> >> test', not 'make test-all'
> >>
> >> Thanks,
> >> Kle

[vpp-dev] make test-all

2017-11-10 Thread Brian Brooks

Should "make test-all" pass?

Thanks,
Brian

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] 128-bit integer scalar type

2017-10-13 Thread Brian Brooks

Hi,

Are there cases where unsigned __int128 can be used instead of u32x4 or 
similar-width vector.h type abstraction for code that does plain C-style 
bitwise/arith ops or assignments?

Thanks,
Brian

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] vhash/pfhash

2017-10-13 Thread Brian Brooks

Hi,

Will vhash and pfhash continue to be unused?
Which hash is used the most often?

Thanks,
Brian

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8

2017-10-02 Thread Brian Brooks

On 10/02 16:17:37, Saxena, Nitin wrote:
> Hi Dave, Brian,
> 
> 
> In VPP v17.07.01. Size of uword on aarch64 machine is 8 byte. 
> (src/vppinfra/types.h) and in my case value of &dq->interrupt_pending is 4 
> byte aligned address which is why I am getting SIGBUS error on my ThunderX2. 
> Am I missing / or doing something error here? Brian are you using 64 bit 
> machine? As I am surprised on all x86_64 and aarch64 machines uword should be 
> 8 byte.

Looks like this patch came after v17.07.01:

  commit 26054ea1d1bad8d0d383bac59bfbe50912aee146
  Author: Christophe Fontaine 
  Date:   Tue Jun 20 13:57:47 2017 +0200

  Fix SIGBUS on aarch64

  A call to 'clib_smp_swap (&((dq)->interrupt_pending), 0)' was creating
  a SIGBUS.
  Instead of making dq->interrupt_pending aligned on 64bits, we reduce the 
size
  from uword (u64) to u32, as the number of pending interrupts will never
  go above max of u32.

  Change-Id: Ifa5a6d3b7adee222329a671be01305cf50853b33
  Signed-off-by: Christophe Fontaine 

  diff --git a/src/vnet/devices/devices.h b/src/vnet/devices/devices.h
  index f1f7e778..b74e3713 100644
  --- a/src/vnet/devices/devices.h
  +++ b/src/vnet/devices/devices.h
  @@ -61,7 +61,7 @@ typedef struct
 u32 dev_instance;
 u16 queue_id;
 vnet_hw_interface_rx_mode mode;
  -  uword interrupt_pending;
  +  u32 interrupt_pending;
   } vnet_device_and_queue_t;

   typedef struct

> I have tested on ThunderX2 that __sync_lock_test_and_set(addr,new) works well 
> on uint32_t data type saved at 4 byte aligned pointer. So that works well.
> 
> 
> Please let me know whats a way forward. Using vec_add2_ha() in such case can 
> be the possible solution since Dave is not in favor of changing vec_add2() 
> with 8 byte default alignment.
> 
> 
> Thanks,
> 
> Nitin
> 
> 
> From: vpp-dev-boun...@lists.fd.io  on behalf of 
> Dave Barach (dbarach) 
> Sent: Saturday, September 30, 2017 2:24 AM
> To: Brian Brooks
> Cc: Narayana, Prasad Athreya; Damjan Marion (damarion); vpp-dev@lists.fd.io; 
> Saxena, Nitin
> Subject: Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8
> 
> As a quick hack: try moving "u32 interrupt_pending;" to the start of the 
> structure...
> 
> Thanks… Dave
> 
> -Original Message-
> From: Brian Brooks [mailto:brian.bro...@arm.com]
> Sent: Friday, September 22, 2017 12:33 PM
> To: Dave Barach (dbarach) 
> Cc: Saxena, Nitin ; vpp-dev@lists.fd.io; Damjan 
> Marion (damarion) ; Narayana, Prasad Athreya 
> 
> Subject: Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8
> 
> On 09/28 11:57:36, Dave Barach (dbarach) wrote:
> > Dear Nitin,
> >
> > First off: exactly which LDXR / STXR instruction variant pairs is 
> > generated? I begin to wonder if __sync_lock_test_and_set(...) might not be 
> > doing you any favors. Given that dq->interrupt_pending is a u32, I would 
> > have expected a 4-byte instruction with (at worst) a 4-byte alignment 
> > requirement.
> 
> It's true that a LDXR of 4 bytes only requires 4 byte alignment (not 8).
> 
> For the TAS, objdump vhost-user.o shows
> 
>   ldxr   w0, [x1]
>   stxr   w3, w2, [x1]
>   cbnz   w3, ..
> 
> These instructions are operating on 4 byte data because of the use of a
> 'w' register instead of a 'x' register to hold the actual value.
> 
> Nitin, can you confirm you see the same generated code? If so, is
> &dq->interrupt_pending 4 byte aligned?
> 
> > Are there any alignment restrictions on the 1-byte variants LDXRB / STXRB?
> >
> > If not: since we use dq->interrupt_pending as a one-bit flag, declaring it 
> > as a u8 - or casting &dq->interrupt_pending to (u8 *) in an arch-dependent 
> > fashion - might make the pain go away.
> >
> > Aligning every vector in the system will waste memory, and will not 
> > legislate this class of problem out of existence. So, I wouldn't want to 
> > force 8-byte alignment in the way you mention.
> >
> > Anyhow, aligning the first vector element to an 8-byte boundary says little 
> > about the layout of elements within each vector element, especially if the 
> > structure is packed.
> >
> > If dq->interrupt_pending needs to be aligned to a specific boundary without 
> > fail, the only completely reliable method would be to pack and pad the 
> > structure e.g. to a multiple of 8 octets and ensure that interrupt_pending 
> > lands on the required boundary. Then use vec_add2_ha (...) to manipulate 
> > the vector.
> >
> > HTH... Dave
> >
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-

[vpp-dev] unit test framework timeout

2017-09-29 Thread Brian Brooks

Is there a way to make:

  FAILFAST=0 TIMEOUT=t make test

actually continue on to the next test if a test has reached timeout t?

The motivation is that I see at least one test case running for forever,
and I want to be able to see how many test cases are failing in total.

I didn't see that this was possible to do out of the box, so I tried one
approach: launch a thread that waits until the timeout has passed and then
send a term signal to the vpp process. If the test case completes before
timeout, the test case's "tearDown" routine will cancel the timeout thread.
The timeout and killing part works, except the test framework still does
not continue on to the next test case.

Thoughts?

Thanks,
Brian
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8

2017-09-29 Thread Brian Brooks

On 09/28 11:57:36, Dave Barach (dbarach) wrote:
> Dear Nitin,
> 
> First off: exactly which LDXR / STXR instruction variant pairs is generated? 
> I begin to wonder if __sync_lock_test_and_set(...) might not be doing you any 
> favors. Given that dq->interrupt_pending is a u32, I would have expected a 
> 4-byte instruction with (at worst) a 4-byte alignment requirement.

It's true that a LDXR of 4 bytes only requires 4 byte alignment (not 8).

For the TAS, objdump vhost-user.o shows

  ldxr   w0, [x1]
  stxr   w3, w2, [x1]
  cbnz   w3, ..

These instructions are operating on 4 byte data because of the use of a
'w' register instead of a 'x' register to hold the actual value.

Nitin, can you confirm you see the same generated code? If so, is
&dq->interrupt_pending 4 byte aligned?

> Are there any alignment restrictions on the 1-byte variants LDXRB / STXRB?
> 
> If not: since we use dq->interrupt_pending as a one-bit flag, declaring it as 
> a u8 - or casting &dq->interrupt_pending to (u8 *) in an arch-dependent 
> fashion - might make the pain go away.
> 
> Aligning every vector in the system will waste memory, and will not legislate 
> this class of problem out of existence. So, I wouldn't want to force 8-byte 
> alignment in the way you mention.
> 
> Anyhow, aligning the first vector element to an 8-byte boundary says little 
> about the layout of elements within each vector element, especially if the 
> structure is packed.
> 
> If dq->interrupt_pending needs to be aligned to a specific boundary without 
> fail, the only completely reliable method would be to pack and pad the 
> structure e.g. to a multiple of 8 octets and ensure that interrupt_pending 
> lands on the required boundary. Then use vec_add2_ha (...) to manipulate the 
> vector.
> 
> HTH... Dave
> 
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Saxena, Nitin
> Sent: Thursday, September 28, 2017 4:53 AM
> To: vpp-dev@lists.fd.io
> Cc: Narayana, Prasad Athreya 
> Subject: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8
> 
> 
> Hi All,
> 
> 
> 
> I got a crash with vpp v17.07.01 on ARMv8 Soc 
> @src/vnet/devices/virtio/vhost-user.c: Line no: 1852
> 
> 
> if (clib_smp_swap (&dq->interrupt_pending, 0) ||
> (node->state == VLIB_NODE_STATE_POLLING)){
> }
> 
> While debugging it turns out that value of (&dq->interrupt_pending) was not 8 
> byte aligned hence causing SIGBUS error on ARMv8 SoC. Further debugging tells 
> that dq was added in vector using vec_add2 (src/vnet/devices/devices.c Line 
> no: 152)
> 
> vec_add2 (rt->devices_and_queues, dq, 1)
> 
> which uses 0 byte alignment. Changing vec_add2 to vec_add2_aligned() fixed 
> the problem. My question is can we completely define vec_add2() as
> 
> #define vec_add2(V,P,N)   vec_add2_ha(V,P,N,0,8) instead of #define 
> vec_add2(V,P,N)   vec_add2_ha(V,P,N,0,0)
> 
> This can be helpful for all architecture.
> 
> Thanks,
> Nitin
> 
> 
> 

> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [vhost-user][armv8][v1704]: VPP crashes while giving IP to VM interface

2017-09-21 Thread Brian Brooks

Try with CLIB_LOG2_CACHE_LINE_BYTES=6?

vlib_get_buffer_index() has changed since v1704. Are you able to try the tip of 
tree?

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Saxena, Nitin
Sent: Wednesday, September 20, 2017 3:03 PM
To: vpp-dev@lists.fd.io
Cc: Narayana, Prasad Athreya 
Subject: Re: [vpp-dev] [vhost-user][armv8][v1704]: VPP crashes while giving IP 
to VM interface

Hi,

I further debugged this issue. It turns out that 
vlib_buffer_get_buffer_free_list (vlib_main_t * vm, vlib_buffer_t * b,u32 * 
index) returns corrupted fl (free list) pointer. This is happening because 
((vlib_buffer_t *) b)->free_list_index in function vlib_get_buffer_free_list() 
is corrupt. ((vlib_buffert_t *)b)->free_list_index or infact b comes from 
vlib_get_buffer(). I am thinking that the (vlib_buffer_t *)b returned by 
vlib_get_buffer() is incorrect. vlib_get_buffer() return offset using 
vm->physmem_main.

I tried running same scenario with dbg binaries as above issue was with release 
binaries.
With debug binaries I saw SIGABRT raised due to assert in 
vlib_get_buffer_index() called by fill_free_list() function.

always_inline u32
vlib_get_buffer_index (vlib_main_t * vm, void *p)
{
  uword offset = vlib_physmem_offset_of (&vm->physmem_main, p);
  ASSERT ((offset % (1 << CLIB_LOG2_CACHE_LINE_BYTES)) == 0);
  return offset >> CLIB_LOG2_CACHE_LINE_BYTES;
}

So I feel some how in both the cases vm->physmem_main is not properly setup for 
my vhost-driver. Both issues (with release binary and debug binary) occur only 
when I assign IP address to interface inside VM1 and each time VPP host process 
crashes.

Attached crash dump with debug binaries. I have attached crash dumps with 
release binaries in earlier mail. Any pointer will be helpful.

Thanks,
Nitin

On 15-Sep-2017, at 7:33 PM, Saxena, Nitin 
mailto:nitin.sax...@cavium.com>> wrote:

Hi All,

I am trying vhost-user configuration on Cavium's aarch64 SoC using VPP v1704. I 
mainly followed steps provided at following

https://wiki.fd.io/view/VPP/Use_VPP_to_connect_VMs_Using_Vhost-User_Interface

I am able to launch two VM's using qemu-system-aarch64. The host and guest 
kernel version is 4.12.9. I am also able to configure two virtual interface 
described in above documentation link. However as soon as I provide IP address 
to first VM interface using ifconfig orip addr add command, the vpp process on 
host crashes. I was watching "vppctl show_interface" where I saw one packet 
received by vpp at Virtual1 interface and after then I think vpp process 
crashed so vppctl got hang.

I have attached gdb crash dump "gdb_crash_log.txt". I have also attached 
command I used to launch VM1 and VM2: vm1_launch.sh, vm2_launch.sh.

Any pointers will be really helpful.

Thanks,
Nitin

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [EXT] Re: [discuss] Question about VPP support for ARM 64

2017-08-28 Thread Brian Brooks

Hi Eric,

Seeing similar ICEs with GCC 5.3.1. Can you try GCC 5.4.0+?
That might require a newer Ubuntu filesystem than the one
described on the MACCHIATObin wiki. I will be setting up a
MACCHIATObin shortly.

Brian

On 08/26 02:59:33, Eric Chen wrote:
> HI Brian,
> 
> Yes,  I upgrading to Ubuntu 16.04,
> 
> Succedd to Nativly build fd.io_odp4vpp (w / odp-linux), 
> However when buidl fd.io_vpp (w/ dpdk),  it reported below error,
> 
> Anyone met before? Seem a bug of gcc. 
> 
> In file included from 
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/error_funcs.h:43:0,
>  from 
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/vlib.h:70,
>  from 
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vnet/l2/l2_fib.c:19:
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/node_funcs.h: In 
> function ‘vlib_process_suspend_time_is_zero’:
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/node_funcs.h:442:1:
>  error: unable to generate reloads for:
>  }
>  ^
> (insn 11 37 12 2 (set (reg:CCFPE 66 cc)
> (compare:CCFPE (reg:DF 79)
> (reg:DF 80))) 
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/node_funcs.h:441 
> 395 {*cmpedf}
>  (expr_list:REG_DEAD (reg:DF 80)
> (expr_list:REG_DEAD (reg:DF 79)
> (nil
> /home/ericxh/work/git_work/fd.io_vpp/build-data/../src/vlib/node_funcs.h:442:1:
>  internal compiler error: in curr_insn_transform, at lra-constraints.c:3509
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Makefile:6111: recipe for target 'vnet/l2/l2_fib.lo' failed
> make[4]: *** [vnet/l2/l2_fib.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> 
> 
> 
> ericxh@linaro-developer:~/work/git_work/fd.io_vpp$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
> Target: aarch64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
> 5.3.1-14ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-5 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-libquadmath --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 
> --with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror 
> --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu 
> --target=aarch64-linux-gnu
> Thread model: posix
> gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2)
> 
> 
> -Original Message-
> From: Brian Brooks [mailto:brian.bro...@arm.com] 
> Sent: 2017年8月26日 2:00
> To: Eric Chen 
> Cc: George Zhao ; discuss ; 
> csit-dev ; Damjan Marion (damarion) 
> ; vpp-dev 
> Subject: Re: [EXT] Re: [vpp-dev] [discuss] Question about VPP support for ARM 
> 64
> 
> Hi Eric,
> 
> On 08/23 06:23:07, Eric Chen wrote:
> > Hi Brian,
> > 
> > I am trying to natively build vpp in aarch64 box as well,
> > 
> > However when I "make install-dep", it report error -- "unable to 
> > locate package default-jdk-headless",
> > 
> > If you are using Ubuntu as well, could you share with me your apt-get 
> > source list?
> 
> Are you natively building on a MACCHIATObin with the Ubuntu filesystem?
> 
> > Thanks
> > Eric
> > 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] 
> > On Behalf Of Brian Brooks
> > Sent: 2017年8月23日 12:31
> > To: George Zhao 
> > Cc: discuss ; csit-dev ; 
> > Damjan Marion (damarion) ; vpp-dev 
> > 
> > Subject: [EXT] Re: [vpp-dev] [discuss] Question about VPP support for 
> > ARM 64
> > 
> > External Email
> > 
> > --
> > Hi Damjan, George,
> > 
> > I just pulled lastest source and tried native build (platforms/vpp.mk) on 
> > ARMv8:
&

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

2017-08-28 Thread Brian Brooks

On 08/23 08:05:16, Damjan Marion (damarion) wrote:
> 
> On 23 Aug 2017, at 06:30, Brian Brooks 
> mailto:brian.bro...@arm.com>> wrote:
> 
> Hi Damjan, George,
> 
> I just pulled lastest source and tried native build (platforms/vpp.mk) on 
> ARMv8:
> 
>  cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory
> 
> From dpdk/Makefile,
> 
>  
> ##
>  # Intel x86
>  
> ##
>  ifeq ($(MACHINE),$(filter $(MACHINE),x86_64 i686))
>  DPDK_TARGET   ?= $(MACHINE)-native-linuxapp-$(DPDK_CC)
>  DPDK_MACHINE  ?= nhm
>  DPDK_TUNE ?= core-avx2
>  
> ##
>  # Cavium ThunderX
>  
> ##
>  else ifneq (,$(findstring thunder,$(shell cat 
> /sys/bus/pci/devices/:00:01.0/uevent | grep cavium)))
>  export CROSS=""
>  DPDK_TARGET   ?= arm64-thunderx-linuxapp-$(DPDK_CC)
>  DPDK_MACHINE  ?= thunderx
>  DPDK_TUNE ?= generic
> 
> So, I am thinking we need to modify this to support MACHINE=aarch64 and 
> possibly
> rework thunder detection to not fail hard on non-thunder machines.
> 
> Yes, unfortunately I don’t have non-thunder system to take care for this but 
> should be easy.

Hi Damjan, George,

Please see https://gerrit.fd.io/r/#/c/8228/ for the change described above.

Thanks,
Brian

> Another thing which needs attention is proper cacheline size detection  
> during vpp build. thunder-x have 128 byte cacheline
> and others are 64 if i get it right. Last time I was looking there was no way 
> to find it out from sysfs but maybe new kernels
> expose that info.
> 
> 
> Regards,
> Brian
> 
> On 08/22 17:55:20, George Zhao wrote:
> Thanks Demjan,
> 
> Confirmed that your patches worked on our system as well.
> 
> George
> 
> From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
> Sent: Tuesday, August 22, 2017 5:03 AM
> To: George Zhao
> Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
> Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> Dear George,
> 
> I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
> minor issues (all patches submitted to master) I got VPP running.
> I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel in my 
> attempts to get system working)
> 
> For me it is hard to help you with your particular system, as I don’t have 
> access to similar one, but my guess is that it shouldn’’t be too hard to get 
> it working.
> 
> Thanks,
> 
> Damjan
> 
> On 20 Aug 2017, at 23:12, George Zhao 
> mailto:george.y.z...@huawei.com><mailto:george.y.z...@huawei.com>>
>  wrote:
> 
> Hi Damian,
> 
> IT is Applied Micro overdrive 1000, here are the uname -a output:
> 
> $>> uname -a
> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
> aarch64 aarch64 aarch64 GNU/Linux
> 
> thanks
> George
> 发件人：Damjan Marion (damarion)
> 收件人：George Zhao
> 抄送：dbarach,discuss,csit-dev,vpp-dev
> 时间：2017-08-20 10:03:27
> 主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> 
> 
> George, are you using ThunderX platform?
> 
> I spent few hours today trying to install latest ubuntu on my ThunderX system 
> but no luck, kernel hangs at some point, both ubuntu provided and manually 
> compiled.
> 
> Can you share about more details about your system?
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> On 19 Aug 2017, at 22:48, George Zhao 
> mailto:george.y.z...@huawei.com><mailto:george.y.z...@huawei.com>>
>  wrote:
> 
> If a bug is filed, may I have the bug number, I would be love to trace this 
> patch.
> 
> BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> 
> Thanks,
> George
> 
> -Original Message-
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Saturday, August 19, 2017 7:42 AM
> To: George Zhao 
> mailto:george.y.z...@huawei.com><mailto:george.y.z...@huawei.com>>
> Cc: 
> vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io><mailto:vpp-dev@lists.fd.io>; 
> disc...@lists.fd.io<mailto:disc...@lists.fd.io><mailto:disc...@lists.fd.io>; 
> csit-...@lists.fd.io<mailto:csit-...@lists.fd.io><mailto:csit-...@lists.fd.io>;
>  Damjan Marion (damarion) 
> mailto:damar...@cisco.com><mailto:damar...@cisco.com>>
> Sub

Re: [vpp-dev] [EXT] Re: [discuss] Question about VPP support for ARM 64

2017-08-25 Thread Brian Brooks

Hi Eric,

On 08/23 06:23:07, Eric Chen wrote:
> Hi Brian,
> 
> I am trying to natively build vpp in aarch64 box as well, 
> 
> However when I "make install-dep", it report error -- "unable to locate 
> package default-jdk-headless",
> 
> If you are using Ubuntu as well, could you share with me your apt-get source 
> list?

Are you natively building on a MACCHIATObin with the Ubuntu filesystem?

> Thanks
> Eric
> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Brian Brooks
> Sent: 2017年8月23日 12:31
> To: George Zhao 
> Cc: discuss ; csit-dev ; Damjan 
> Marion (damarion) ; vpp-dev 
> Subject: [EXT] Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> External Email
> 
> --
> Hi Damjan, George,
> 
> I just pulled lastest source and tried native build (platforms/vpp.mk) on 
> ARMv8:
> 
>   cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory
> 
> From dpdk/Makefile,
> 
>   
> ##
>   # Intel x86
>   
> ##
>   ifeq ($(MACHINE),$(filter $(MACHINE),x86_64 i686))
>   DPDK_TARGET   ?= $(MACHINE)-native-linuxapp-$(DPDK_CC)
>   DPDK_MACHINE  ?= nhm
>   DPDK_TUNE ?= core-avx2
>   
> ##
>   # Cavium ThunderX
>   
> ##
>   else ifneq (,$(findstring thunder,$(shell cat 
> /sys/bus/pci/devices/:00:01.0/uevent | grep cavium)))
>   export CROSS=""
>   DPDK_TARGET   ?= arm64-thunderx-linuxapp-$(DPDK_CC)
>   DPDK_MACHINE  ?= thunderx
>   DPDK_TUNE ?= generic
> 
> So, I am thinking we need to modify this to support MACHINE=aarch64 and 
> possibly rework thunder detection to not fail hard on non-thunder machines.
> 
> Regards,
> Brian
> 
> On 08/22 17:55:20, George Zhao wrote:
> > Thanks Demjan,
> > 
> > Confirmed that your patches worked on our system as well.
> > 
> > George
> > 
> > From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
> > Sent: Tuesday, August 22, 2017 5:03 AM
> > To: George Zhao
> > Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
> > Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> > 
> > Dear George,
> > 
> > I tried on my Cavium ThunderX system with latest Ubuntu and after fixing 
> > few minor issues (all patches submitted to master) I got VPP running.
> > I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel 
> > in my attempts to get system working)
> > 
> > For me it is hard to help you with your particular system, as I don’t have 
> > access to similar one, but my guess is that it shouldn’’t be too hard to 
> > get it working.
> > 
> > Thanks,
> > 
> > Damjan
> > 
> > On 20 Aug 2017, at 23:12, George Zhao 
> > mailto:george.y.z...@huawei.com>> wrote:
> > 
> > Hi Damian,
> > 
> > IT is Applied Micro overdrive 1000, here are the uname -a output:
> > 
> > $>> uname -a
> > Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 
> > 2017 aarch64 aarch64 aarch64 GNU/Linux
> > 
> > thanks
> > George
> > 发件人：Damjan Marion (damarion)
> > 收件人：George Zhao
> > 抄送：dbarach,discuss,csit-dev,vpp-dev
> > 时间：2017-08-20 10:03:27
> > 主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> > 
> > 
> > 
> > George, are you using ThunderX platform?
> > 
> > I spent few hours today trying to install latest ubuntu on my ThunderX 
> > system but no luck, kernel hangs at some point, both ubuntu provided and 
> > manually compiled.
> > 
> > Can you share about more details about your system?
> > 
> > Thanks,
> > 
> > Damjan
> > 
> > 
> > 
> > > On 19 Aug 2017, at 22:48, George Zhao 
> > > mailto:george.y.z...@huawei.com>> wrote:
> > >
> > > If a bug is filed, may I have the bug number, I would be love to trace 
> > > this patch.
> > >
> > > BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> > >
> > > Thanks,
> > > George
> > >
> > > -Original Message-
> > > From: D

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

2017-08-22 Thread Brian Brooks

Hi Damjan, George,

I just pulled lastest source and tried native build (platforms/vpp.mk) on ARMv8:

  cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory

From dpdk/Makefile,

  ##
  # Intel x86
  ##
  ifeq ($(MACHINE),$(filter $(MACHINE),x86_64 i686))
  DPDK_TARGET   ?= $(MACHINE)-native-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= nhm
  DPDK_TUNE ?= core-avx2
  ##
  # Cavium ThunderX
  ##
  else ifneq (,$(findstring thunder,$(shell cat 
/sys/bus/pci/devices/:00:01.0/uevent | grep cavium)))
  export CROSS=""
  DPDK_TARGET   ?= arm64-thunderx-linuxapp-$(DPDK_CC)
  DPDK_MACHINE  ?= thunderx
  DPDK_TUNE ?= generic

So, I am thinking we need to modify this to support MACHINE=aarch64 and possibly
rework thunder detection to not fail hard on non-thunder machines.

Regards,
Brian

On 08/22 17:55:20, George Zhao wrote:
> Thanks Demjan,
> 
> Confirmed that your patches worked on our system as well.
> 
> George
> 
> From: Damjan Marion (damarion) [mailto:damar...@cisco.com]
> Sent: Tuesday, August 22, 2017 5:03 AM
> To: George Zhao
> Cc: Dave Barach (dbarach); discuss; csit-dev; vpp-dev
> Subject: Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> Dear George,
> 
> I tried on my Cavium ThunderX system with latest Ubuntu and after fixing few 
> minor issues (all patches submitted to master) I got VPP running.
> I use latest Ubuntu devel (17.10, mainly as I upgraded to new kernel in my 
> attempts to get system working)
> 
> For me it is hard to help you with your particular system, as I don’t have 
> access to similar one, but my guess is that it shouldn’’t be too hard to get 
> it working.
> 
> Thanks,
> 
> Damjan
> 
> On 20 Aug 2017, at 23:12, George Zhao 
> mailto:george.y.z...@huawei.com>> wrote:
> 
> Hi Damian,
> 
> IT is Applied Micro overdrive 1000, here are the uname -a output:
> 
> $>> uname -a
> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
> aarch64 aarch64 aarch64 GNU/Linux
> 
> thanks
> George
> 发件人：Damjan Marion (damarion)
> 收件人：George Zhao
> 抄送：dbarach,discuss,csit-dev,vpp-dev
> 时间：2017-08-20 10:03:27
> 主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64
> 
> 
> 
> George, are you using ThunderX platform?
> 
> I spent few hours today trying to install latest ubuntu on my ThunderX system 
> but no luck, kernel hangs at some point, both ubuntu provided and manually 
> compiled.
> 
> Can you share about more details about your system?
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> > On 19 Aug 2017, at 22:48, George Zhao 
> > mailto:george.y.z...@huawei.com>> wrote:
> >
> > If a bug is filed, may I have the bug number, I would be love to trace this 
> > patch.
> >
> > BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> >
> > Thanks,
> > George
> >
> > -Original Message-
> > From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> > Sent: Saturday, August 19, 2017 7:42 AM
> > To: George Zhao mailto:george.y.z...@huawei.com>>
> > Cc: vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io; Damjan Marion (damarion) 
> > mailto:damar...@cisco.com>>
> > Subject: RE: [discuss] Question about VPP support for ARM 64
> >
> > +1, pls add the typedef...
> >
> > Thanks… Dave
> >
> > -Original Message-
> > From: Damjan Marion (damarion)
> > Sent: Saturday, August 19, 2017 9:09 AM
> > To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> > Cc: George Zhao 
> > mailto:george.y.z...@huawei.com>>; 
> > vpp-dev@lists.fd.io; 
> > disc...@lists.fd.io; 
> > csit-...@lists.fd.io
> > Subject: Re: [discuss] Question about VPP support for ARM 64
> >
> >
> > GCC is able to compile ARM64 code with 256-bit vectors even if target 
> > platform have only 128-bit registers.
> >
> > I.e. for the u8x32 version of that function it generates:
> >
> > ARM64:
> > dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> >ld1 {v0.16b - v1.16b}, [x4], 32
> >st1 {v0.16b - v1.16b}, [x3], 32
> >st1 {v0.16b - v1.16b}, [x2], 32
> >st1 {v0.16b - v1.16b}, [x1], 32
> >st1 {v0.16b - v1.16b}, [x0], 32
> >ld1 {v0.16b - v1.16b}, [x4]
> >st1 {v0.16b - v1.16b}, [x3]
> >st1 {v0.16b - v1.16b}, [x2]
> >st1 {v0.16b - v1.16b}, [x1]
> >st1 {v0.16b - v1.16b}, [x0]
> >ret
> >
> > intel x86-64 without AVX2:
> >
> > dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> >

Re: [vpp-dev] VPP ARM Build/Installation

[vpp-dev] when is make test-all run?

Re: [vpp-dev] vlib_main() taking maximum cycle in v1804 release

Re: [vpp-dev] VPP with DPDK eventdev

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

Re: [vpp-dev] Trying to build vpp on amd64 platform via qemu static library qemu-aarch64-static in Docker container

Re: [vpp-dev] [Fwd: [dpdk-dev] DPDK 18.02 on ARM64 is broken]

Re: [vpp-dev] aarch64 compilation break

Re: [vpp-dev] aarch64 compilation break

Re: [vpp-dev] Vpp service not stopping on Arm64.

Re: [vpp-dev] make test-all

[vpp-dev] make test-all

[vpp-dev] 128-bit integer scalar type

[vpp-dev] vhash/pfhash

Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8

[vpp-dev] unit test framework timeout

Re: [vpp-dev] [v17.07.01]: vec_add2() causing crash on ARMv8

Re: [vpp-dev] [vhost-user][armv8][v1704]: VPP crashes while giving IP to VM interface

Re: [vpp-dev] [EXT] Re: [discuss] Question about VPP support for ARM 64

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

Re: [vpp-dev] [EXT] Re: [discuss] Question about VPP support for ARM 64

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

24 matches

Site Navigation

Mail list logo

Footer information