Fd.io VPP on LX2160?

NXP LX2160
1

Dear SolidRun community members,

Does anybody have any experience or attempts to run fd.io VPP dataplane on LX2160 platform?

I already have some attempts to do that, with unsatisfactory results. The performance was quite attractive, about 4.5mpps per CPU core, which is more then ten-fold comparing to Linux core. But I was not able to produce build stable enough.
I need Linux-CP plugin to interact with Control-plane applications, so I have to use more recent versions.
Our experiments shows following.

  1. Vanilla VPP build, from github, is not working at all. It segfaults on 0x4 when attempting to register DPAA2 interfaces.

  2. When using patches from LSDK (qoriq.codeaurora., applied to code same way they applied in LSDK versions, then building the app by LSDK documentation, the build can start and register DPAA2 interfaces, but it is really unstable and crashes after minutes or hours without clear reason. The most effective way to crash it is initialization of TAP interfaces in Linux-CP plugin, or to start multiple vppctl’s
    Different compilers, different optimization settings, different memory settings, all does not help.

The platform looks really attractive for DPDK/VPP networking applications due to good DPDK/VPP performance for low power consumption. It’s hard to believe that nobody else tried to use VPP on it. If anybody here do that, can you please share your experience?

Below is trace from one of crashes.

Thread 1 “vpp_main” received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at …/sysdeps/unix/sysv/linux/raise.c:50
50 …/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at …/sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000fffff6d7caac in __GI_abort () at abort.c:79
#2 0x0000000000406fe4 in os_panic () at /work/build/vpp/src/vpp/vnet/main.c:416
#3 0x0000fffff6fa6514 in debugger () at /work/build/vpp/src/vppinfra/error.c:84
#4 0x0000fffff6fa6874 in _clib_error (how_to_die=2, function_name=0xfffff7173978 <FUNCTION.32141> “vlib_buffer_validate_alloc_free”, line_number=333,
fmt=0xfffff7173438 “%s %U buffer 0x%x”) at /work/build/vpp/src/vppinfra/error.c:143
#5 0x0000fffff70c1218 in vlib_buffer_validate_alloc_free (vm=0xffffb6d5c740, buffers=0xffffb4bac810, n_buffers=1, expected_state=VLIB_BUFFER_KNOWN_ALLOCATED)
at /work/build/vpp/src/vlib/buffer.c:332
#6 0x0000fffff716afc4 in vlib_buffer_pool_put (vm=0xffffb6d5c740, buffer_pool_index=0 ‘\000’, buffers=0xffffb4bac810, n_buffers=1)
at /work/build/vpp/src/vlib/buffer_funcs.h:731
#7 0x0000fffff716b75c in vlib_buffer_free_inline (vm=0xffffb6d5c740, buffers=0xffffb88bd1d4, n_buffers=0, maybe_next=1) at /work/build/vpp/src/vlib/buffer_funcs.h:917
#8 0x0000fffff716b7c8 in vlib_buffer_free (vm=0xffffb6d5c740, buffers=0xffffb88bd1d0, n_buffers=1) at /work/build/vpp/src/vlib/buffer_funcs.h:936
#9 0x0000fffff716c424 in process_drop_punt (vm=0xffffb6d5c740, node=0xffffb7844300, frame=0xffffb88bd1c0, disposition=ERROR_DISPOSITION_DROP)
at /work/build/vpp/src/vlib/drop.c:235
#10 0x0000fffff716c4fc in error_drop_node_fn_cortexa72 (vm=0xffffb6d5c740, node=0xffffb7844300, frame=0xffffb88bd1c0) at /work/build/vpp/src/vlib/drop.c:251
#11 0x0000fffff70f512c in dispatch_node (vm=0xffffb6d5c740, node=0xffffb7844300, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0xffffb88bd1c0,
last_time_stamp=233164692224) at /work/build/vpp/src/vlib/main.c:960
#12 0x0000fffff70f585c in dispatch_pending_node (vm=0xffffb6d5c740, pending_frame_index=4, last_time_stamp=233164692224) at /work/build/vpp/src/vlib/main.c:1119
#13 0x0000fffff70f6be8 in vlib_main_or_worker_loop (vm=0xffffb6d5c740, is_main=1) at /work/build/vpp/src/vlib/main.c:1588
#14 0x0000fffff70f71ec in vlib_main_loop (vm=0xffffb6d5c740) at /work/build/vpp/src/vlib/main.c:1716
#15 0x0000fffff70f7d1c in vlib_main (vm=0xffffb6d5c740, input=0xffffb4badfc8) at /work/build/vpp/src/vlib/main.c:2010
#16 0x0000fffff7145044 in thread0 (arg=281473749206848) at /work/build/vpp/src/vlib/unix/main.c:667
#17 0x0000fffff6fb84c0 in clib_calljmp () at /work/build/vpp/src/vppinfra/longjmp.S:809
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

2

I have not tested this personally. I asked on the discord channel to see if any other community members there have attempted to use it.

3

One additional remark. I was trying to run it on SolidRun builds, and found strange issue.

My first attempt was in May, lx2160acex7_2000_700_3200_8_5_2-ddab3ad.img.xz image. dpdk test-pmd works, vpp works unstable.
Later, in November, I updated to new image, lx2160acex7_xspi_2000_700_3200_8_5_2-33cddb7.img.xz and later. vpp starts, but cannot see any packets with TenGigabitEthernet0-tx Tx packet drops (dpdk tx failure) error .
dpdk-testpmd cannot see interfaces.
In same time, I’ve build my own images with some minor custom settings (addressing, naming, users, etc), and same thing with DPDK not working. It looks like, somewhere between July and November something changed and impacted DPDK work.

Any ideas what could it be?