Topics

First post, 32bit question

Tom Bakita <Tom.Bakita@...>
 

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? 

Thanks!
Tom

  CCLD     libvppapiclient.la
/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 -fPIC
./.libs/libsvm.a(svm.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status



Dave Barach
 

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/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...

 

HTH… Dave

 

From: vpp-dev@... [mailto:vpp-dev@...] On Behalf Of Tom Bakita
Sent: Friday, February 9, 2018 1:59 PM
To: vpp-dev@...
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? 

 

Thanks!

Tom

 

  CCLD     libvppapiclient.la

/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 -fPIC

./.libs/libsvm.a(svm.o): error adding symbols: Bad value

collect2: error: ld returned 1 exit status