Dear Tom,

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 
compiler flags].

Copy build-data/platforms/ to [if you haven’t already done so], 
and adjust it.

Please do not touch build-root/Makefile. That’s a mistake...

HTH… Dave

From: [] 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

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

Reply via email to