Have you come across vpp_lite yet:
https://wiki.fd.io/view/VPP/Alternative_builds#vpp-lite
It builds vpp without DPDK (used for various testing purposes)
Ed
On Thu, Jan 5, 2017 at 12:19 PM, Sreejith Surendran Nair <
sreejith.surendrann...@linaro.org> wrote:
> Hi All,
>
> I am currently working
Hi All,
I am currently working on ODP(open data plane) integration with VPP for
pktio support.
The ODP internally uses DPDK to detect the hardware NIC ports.
Can I build VPP completely without existing DPDK support so that ODP can
detect the hardware port directly using internal odp-dpdk API fram
There is a pending patch to use ISA-L rather than the Intel IPsec MB lib.
Just FYI.
On Thu, Jan 5, 2017 at 7:14 AM, Maciek Konstantynowicz (mkonstan)
wrote:
> Sergio, thx for following up. Are VPP packages with Cryptodev built today as
> part of any of the vpp verify jobs? Cause they should be,
The VPP as Router between Namespaces tutorial on the Wiki (
https://wiki.fd.io/view/VPP/Configure_VPP_As_A_Router_Between_Namespaces)
shows how to add a host interface using the Command-Line arguments:
cat /etc/vpp/startup.conf
:
dpdk {
no-pci
vdev eth_af_packet0,iface=vpp1
vdev eth_af_pa
Hi,
the modification timestamp of .py is stored inside .pyc... According to
what I found, the .pyc begins with 4 magic bytes, followed by 4
timestamp bytes (source file modification timestamp) and the rest
is the marshalled code object.
So doing a touch a.py, touch a.pyc won't fool it, since it d
I can see the problem:
in vpp.mk, vpp_dpdk_arch is set to native, as you are in the NOT x86_64
case. Leads to DPDK_MARCH set to native in dpdk/Makefile and hence
RTE_MACHINE set to native. When you get to the DPDK build system, native
always means some operating system and some compiler, but alway
Hi Klement,
We’re patching mpls.py – in include nsh.py for reference.
This run worked:
-rw-r--r-- 1 nranns nranns918 2017-01-05 08:15:39.151230150 -0500 mpls.py
-rw-r--r-- 1 nranns nranns 1499 2017-01-05 08:15:39.655234966 -0500 mpls.pyc
-rw-r--r-- 1 nranns nranns 2737 2017-01-05 08:15:3
Yep, seems to be it.
Not sure how to handle this forward. Testing with python is not ideal
for timing checks...
A better test would be to isolate the BFD node from VPP, mock the VPP
infrastructure (node scheduling) and verify that it is sending the frames
out in a timely fashion (all this in C, emu
For me on a not very fast xhyve VM with ubuntu 16.04 (my macbook pro)
on master the BFD tests appear racy, see below.
Is that supposed to happen ?
My results of "make test" on master:
==
ERROR: verify session goes down after in
Sergio, thx for following up. Are VPP packages with Cryptodev built today as
part of any of the vpp verify jobs? Cause they should be, and depositing them
in nexus on merge into master should be the default IMV. If so, CSIT will just
take these from nexus.
vpp-dev, could anybody advise here fur
Neale,
the byte code should be always updated if out of date on import, if
it's not so, then that would be a python bug, which seems improbable.
If you are able to repro this, could you check the timestamps for the
correspoding .py/.pyc files? Maybe somehow the .py file's timestamp is
in the past
Hi Dave,
After a little more experimentation I think this error is related to the way we
patch scapy post install. The scapy installation comes with byte code, after we
apply the patch this byte code may or may not be updated. If I force the
generation of the byte code by either ‘touch /mpls.py
On Wed, 2017-01-04 at 12:03 -0500, Burt Silverman wrote:
> Marco, it looks like the vpp.mk and vpp_lite.mk make an effort to distinguish
> between x86_64 and NOT x86_64, but do not go beyond that. I agree it sounds
> like that could be fleshed out for thunderx, so you can get some optimal
> values
On Wed, 2017-01-04 at 16:46 +, Christophe FONTAINE wrote:
> Hi Marco,
>
> I'm a bit surprised you had a lot of issues compiling directly on the board: I
> don't have a ThunderX board to test, but I just built vpp on a nxp1043, which
> is an armv8 platform.
> And just like you, no cross compila
Dave, there is no sign of test framework installing/patching scapy in
the log you provided.
Could you please do in the same workspace
make test-wipe
and then run the make test again? I don't think it'll actually help us,
because there should be no way for a python inside virtualenv to get its
ha
15 matches
Mail list logo
