Most binary APIs should work perfectly over an AF_UNIX socket. It’s easy to
clean up any broken APIs you might find. All of the message definitions are
__attribute__((packed)), and in network byte order. An i686 control-plane won’t
have issues processing them. See also vpp_api_test.
Please think hard about whether you really need to build the dataplane as an
i686 binary. Although vpp has worked when built for i686 in the past, we don’t
test in that environment. You can expect trouble; exactly the sort of trouble
that folks who are new to the code base simply do not need.
If you decide to go ahead w/ a 32-bit data plane binary, the quickest path from
start to finish would be to spin up either an Ubuntu 16.04 LTS or a CentOS 7.x
i686 VM, and compile w/ vpp w/ an appropriate TAG definition [to set the
Copy build-data/platforms/vpp.mk to vpp32.mk [if you haven’t already done so],
and adjust it.
Please do not touch build-root/Makefile. That’s a mistake...
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Tom Bakita
Sent: Friday, February 9, 2018 1:59 PM
Subject: [vpp-dev] First post, 32bit question
Hi, I’m new to this thread. Short introduction, watched most of the videos
from you session in France, thanks for making that available!. I’m based in
San Jose, CA. I have a multi-layer switch that is ported from an embedded
system to x86. It has a fully functional control plane and does a vast number
of functions, from L2 provider bridging to L3 routing protocols and IP/MPLS,
better said it is a PE. On embedded platforms it programs network processors
for the forwarding plane. For x86 it currently uses software interrupts for
ever packet in the data plane and I’m at the point now where it is time to
address the data plane. Your project looks perfect for this, namely a fast
forwarding plane for x86. I’m genuinely excited about this.
My plan is to use the C-API to program VPP as the forwarding plane, because the
control plane interface is all C. Really just starting out, but one particular
situation is this control plane is currently 32bit (not 64bit safe and I
something I don’t want to tackle right now). So I am building VPP 32bit to
establish the foundation. I changed build-root/Makefile as:
# x86_64 can be either 32/64. set BIACH=32 to get 32 bit libraries.
#BIARCH = 64
BIARCH = 32
Then rebuild with "make V=0 PLATFORM=vpp TAG=vpp32 install-deb”. It runs into
the error below, because svm.o is getting generated as 64bit. I’m on UBUNTU
16.04 and VPP 18.01. While I sort this out I thought I’d ask if I’m on the
right track here planning to use VPP on x86 in 32bit mode?
/usr/bin/ld: ./.libs/libsvm.a(svm.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
./.libs/libsvm.a(svm.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status