Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

2017-08-15 Thread Pragash Vijayaragavan
Hi,

We recently faced a similar issue, we could not insert more than say 500k
routes in ip6 fib table.

https://wiki.fd.io/view/VPP/Command-line_Arguments#.22heapsize.22_parameter

we refered the above link and made the following changes in
/etc/vpp/startup.conf file

ip6 {
  heap-size 4G
}

If you trace back, this parameter makes a call to

/*

* The size of the hash table

*/

#define L2FIB_NUM_BUCKETS (64 * 1024)

#define L2FIB_MEMORY_SIZE (256<<20)


and sets the memory size.



HTH





Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu
ph : 585 764 4662


On Tue, Aug 15, 2017 at 8:05 AM, John Lo (loj)  wrote:

> Hi Billy,
>
>
>
> The output of “show l2fib” is showing how many MAC entries exist in the
> L2FIB and is not relevant to the size of L2FIB table. The L2FIB table size
> is not configurable. It is a bi-hash table with size set by the following
> #def’s in l2_fib.h and has not changed for quite a while, definitely not
> between 1704, 1707 and current master:
>
> /*
>
> * The size of the hash table
>
> */
>
> #define L2FIB_NUM_BUCKETS (64 * 1024)
>
> #define L2FIB_MEMORY_SIZE (256<<20)
>
>
>
> It is interesting to note that at the end of the test run, there is
> different number of MAC entries in the L2FIB. I think this may have to do
> with a change in 1707 where an interface up/down would cause MACs learned
> on that interface to be flushed. So when the interface come back up, the
> MACs needs to be learned again.  With 1704, the stale learned MACs from an
> interface will remain in L2FIB even if the interface is down or deleted
> unless aging is enabled to removed them at the BD aging interval.
>
>
>
> Another improvement added in 1707 was a check in the l2-fwd node so when a
> MAC entry is found in L2FIB, its sequence number is checked to make sure it
> is not stale and subject to flushing (such as MAC learned when this
> interface sw_if_index was up but went down, or if this sw_if_index was
> used, deleted and reused). If the MAC is stale, the packet will be flooded
> instead of making use of the stale MAC entry to forward it.
>
>
>
> I wonder if the test script for the performance does create/delete
> interfaces or set interface to admin up/down states causing stale MACs be
> flushed in 1707?  With 1704, it may be using stale MAC entries to forward
> packets rather than flooding to learn the MACs again. This can explain the
> l2-flood and l2-input count ratio difference between 1704 and 1707.
>
>
>
> When measuring l2-bridg forwarding performance, are you setup to measure
> the forwarding rate in the steady forwarding state?  If all the 10K or 1M
> flows are started at the same time for a particular test, there will be an
> initial low PPS throughput period when all packets needs to be flooded and
> MACs earned before it settle down to a higher steady state PPS forwarding
> rate. If there is interface flap or other events that causes MAC flush, the
> MAC will needs to be learned again. I wonder if the forwarding performance
> for 10K or 1M flows is measure at the steady forwarding state or not.
>
>
>
> Above are a few generic comments I can think of, without knowing much
> details about how the tests are setup and measured. Hope it can help to
> explain the different behavior observed between 1704 and 1707.
>
>
>
> Regards,
>
> John
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Billy McFall
> *Sent:* Monday, August 14, 2017 6:40 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] VPP Performance drop from 17.04 to 17.07
>
>
>
> In the last VPP call, I reported some internal Red Hat performance testing
> was showing a significant drop in performance between releases 17.04 to
> 17.07. This with l2-bridge testing - PVP - 0.002% Drop Rate:
>
>VPP-17.04: 256 Flow 7.8 MP/s 10k Flow 7.3 MP/s 1m Flow 5.2 MP/s
>
>VPP-17.07: 256 Flow 7.7 MP/s 10k Flow 2.7 MP/s 1m Flow 1.8 MP/s
>
>
>
> The performance team re-ran some of the tests for me with some additional
> data collected. Looks like the size of the L2 FIB table was reduced in
> 17.07. Below are the number of entries in the MAC Table after the tests are
> run:
>
>17.04:
>
>  show l2fib
>
>  408 l2fib entries
>
>17.07:
>
>  show l2fib
>
>  1067053 l2fib entries with 1048576 learned (or non-static) entries
>
>
>
> This caused more packets to be flooded (see out of 'show node counters'
> below). I looked but couldn't find anything. Is the size of the L2 FIB
> Table table configurable?
>
>
>
> Thanks,
>
> Billy McFall
>
>
>
>
>
> 17.04:
>
>
>
> show node counters
>
>CountNode  Reason
>
> :
>
>  313035313l2-inputL2 input packets
>
> 555726l2-floodL2 flood packets
>
> :
>
>  310115490l2-inputL2 input packets
>
> 824859l2-flood

Re: [vpp-dev] Regarding C API

2017-08-15 Thread Burt Silverman
It appears that there are 2 typos not just one: try -lvatplugin.

Burt

On Tue, Aug 15, 2017 at 1:32 PM, Prabhjot Singh Sethi <
prabh...@techtrueup.com> wrote:

> We are looking forward to use C APIs to configure VPP and are looking at
> https://wiki.fd.io/view/VPP/How_To_Use_The_C_API as a reference.
>
> However following steps mentioned there, we do see a compilation failure
> "failed to find library" for
> VPP_LIBS += -lvat_pliugin
> where it looks like a typo so i have tried using "vat_plugin" as well
> without any success.
>
> can someone help with following
> - is the name of the library correct
> - where can i find this library
>
> Regards,
> Prabhjot
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Regarding C API

2017-08-15 Thread Prabhjot Singh Sethi

We are looking forward to use C APIs to configure VPP and are looking
at https://wiki.fd.io/view/VPP/How_To_Use_The_C_API as a reference.

However following steps mentioned there, we do see a compilation
failure "failed to find library" for 
VPP_LIBS += -lvat_pliugin
where it looks like a typo so i have tried using "vat_plugin" as well
without any success.

can someone help with following
- is the name of the library correct
- where can i find this library

Regards,
Prabhjot

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

2017-08-15 Thread Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
Hmm, I noticed that your system-wide scapy is 2.3.1, while we
specifically use version 2.3.3 in the tests. Also I wonder how it's
possible that the tests pass on centos in gerrit..

Please note that the system-wide or 'pip install'-wide scapy doesn't
matter as make test sets up its own virtualenv (think of it as its own
chroot with all the (python) stuff it needs)...

Quoting Billy McFall (2017-08-15 16:25:19)
>FYI - I was able to run "make test" on my Fedora laptop. I noticed the
>scapy wasn't installed, so I ran "pip uninstall scapy" on the CentOS
>server that is having the issue. Still has the problem.
>Here is the output:
>(virtualenv)[bmcfall@d2fxl02 test]$ scapy 
>INFO: Can't import matplotlib. Won't be able to plot.
>INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
>Traceback (most recent call last):
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/bin/scapy",
>line 25, in 
>    interact()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/main.py",
>line 300, in interact
>    scapy_builtins = __import__("all",globals(),locals(),".").__dict__
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/all.py",
>line 28, in 
>    from scapy.route6 import *
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 273, in 
>    conf.route6 = Route6()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 31, in __init__
>    self.resync()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 44, in resync
>    self.routes = read_routes6()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/arch/linux.py",
>line 283, in read_routes6
>    cset = scapy.utils6.construct_source_candidate_set(d, dp, devaddrs,
>LOOPBACK_NAME)
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
>line 50, in construct_source_candidate_set
>    if in6_isgladdr(addr) or in6_isuladdr(addr):
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
>line 708, in in6_isgladdr
>    return in6_isincluded(str, '2000::', 3)
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
>line 651, in in6_isincluded
>    temp = inet_pton(socket.AF_INET6, addr)
>Billy McFall
>On Tue, Aug 15, 2017 at 10:02 AM, Klement Sekera -X (ksekera - PANTHEON
>TECHNOLOGIES at Cisco) <[1]ksek...@cisco.com> wrote:
> 
>  We do not use the system-wide scapy, instead we install a specific
>  version of scapy which we patch with our own stuff.
> 
>  Could you try "make test-shell" and run scapy from the spawned shell?
> 
>  Thanks,
>  Klement
> 
>  Quoting Billy McFall (2017-08-15 14:26:33)
>  >    Thanks Klement,
>  >    Details:
>  >      OS: CentOS Linux release 7.3.1611
>  >      Kernel: 3.10.0-514.21.1.el7.x86_64
>  >      sudo scapy
>  >      INFO: Can't import python gnuplot wrapper . Won't be able to
>  plot.
>  >      INFO: Can't import PyX. Won't be able to use psdump() or
>  pdfdump().
>  >      Welcome to Scapy (2.3.1)
>  >      >>>
>  >    Let me know if there is something else that would help.
>  >    Billy
>  >    On Tue, Aug 15, 2017 at 4:02 AM, Klement Sekera -X (ksekera -
>  PANTHEON
>  >    TECHNOLOGIES at Cisco) <[1][2]ksek...@cisco.com> wrote:
>  >
>  >      Hi Billy,
>  >
>  >      I haven't seen this issue yet, but it looks like this is a scapy
>  issue
>  >      on your box. Scapy is a 3rd party library which we use in the
>  test
>  >      framework. What is the exact version of your OS etc?
>  >
>  >      Thanks,
>  >      Klement
>  >
>  >      Quoting Billy McFall (2017-08-14 21:30:35)
>  >      >    I am trying to run "make test" on a CentOS bare metal
>  server. I'm
>  >      getting
>  >      >    "Exception: Illegal syntax for IP address". What do I need
>  to
>  >      >    setup/configure on my server before running "make test"?
>  >      >    Thanks,
>  >      >    Billy McFall
>  >      >    $ make test V=2
>  >      >    make -C
>  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root
>  >      >    PLATFORM=vpp TAG=vpp 

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

2017-08-15 Thread Billy McFall
FYI - I was able to run "make test" on my Fedora laptop. I noticed the
scapy wasn't installed, so I ran "pip uninstall scapy" on the CentOS server
that is having the issue. Still has the problem.


Here is the output:
(virtualenv)[bmcfall@d2fxl02 test]$ scapy
INFO: Can't import matplotlib. Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
Traceback (most recent call last):
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/bin/scapy",
line 25, in 
interact()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/main.py",
line 300, in interact
scapy_builtins = __import__("all",globals(),locals(),".").__dict__
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/all.py",
line 28, in 
from scapy.route6 import *
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 273, in 
conf.route6 = Route6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 31, in __init__
self.resync()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 44, in resync
self.routes = read_routes6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/arch/linux.py",
line 283, in read_routes6
cset = scapy.utils6.construct_source_candidate_set(d, dp, devaddrs,
LOOPBACK_NAME)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 50, in construct_source_candidate_set
if in6_isgladdr(addr) or in6_isuladdr(addr):
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 708, in in6_isgladdr
return in6_isincluded(str, '2000::', 3)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 651, in in6_isincluded
temp = inet_pton(socket.AF_INET6, addr)

Billy McFall


On Tue, Aug 15, 2017 at 10:02 AM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> We do not use the system-wide scapy, instead we install a specific
> version of scapy which we patch with our own stuff.
>
> Could you try "make test-shell" and run scapy from the spawned shell?
>
> Thanks,
> Klement
>
> Quoting Billy McFall (2017-08-15 14:26:33)
> >Thanks Klement,
> >Details:
> >  OS: CentOS Linux release 7.3.1611
> >  Kernel: 3.10.0-514.21.1.el7.x86_64
> >  sudo scapy
> >  INFO: Can't import python gnuplot wrapper . Won't be able to plot.
> >  INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
> >  Welcome to Scapy (2.3.1)
> >  >>>
> >Let me know if there is something else that would help.
> >Billy
> >On Tue, Aug 15, 2017 at 4:02 AM, Klement Sekera -X (ksekera - PANTHEON
> >TECHNOLOGIES at Cisco) <[1]ksek...@cisco.com> wrote:
> >
> >  Hi Billy,
> >
> >  I haven't seen this issue yet, but it looks like this is a scapy
> issue
> >  on your box. Scapy is a 3rd party library which we use in the test
> >  framework. What is the exact version of your OS etc?
> >
> >  Thanks,
> >  Klement
> >
> >  Quoting Billy McFall (2017-08-14 21:30:35)
> >  >I am trying to run "make test" on a CentOS bare metal server.
> I'm
> >  getting
> >  >"Exception: Illegal syntax for IP address". What do I need to
> >  >setup/configure on my server before running "make test"?
> >  >Thanks,
> >  >Billy McFall
> >  >$ make test V=2
> >  >make -C /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root
> >  >PLATFORM=vpp TAG=vpp vpp-install
> >  >make[1]: Entering directory
> >  >`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
> >  > Arch for platform 'vpp' is native 
> >  > Finding source for dpdk 
> >  > Makefile fragment found in
> >  >
> >  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/
> packages/[1][2]dpdk.mk
> >  >
> >  > Source found in
> >  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/dpdk 
> >  > Arch for platform 'vpp' is native 
> >  > Finding source for vpp 
> >  > Makefile fragment found in
> >  >
> >  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/
> packages/[2][3]vpp.mk
> >  >
> >  > Source found in
> >  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/src 
> >  > Configuring dpdk: nothing to do 
> >  > Building dpdk: nothing 

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

2017-08-15 Thread Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
We do not use the system-wide scapy, instead we install a specific
version of scapy which we patch with our own stuff.

Could you try "make test-shell" and run scapy from the spawned shell?

Thanks,
Klement

Quoting Billy McFall (2017-08-15 14:26:33)
>Thanks Klement,
>Details:
>  OS: CentOS Linux release 7.3.1611
>  Kernel: 3.10.0-514.21.1.el7.x86_64
>  sudo scapy
>  INFO: Can't import python gnuplot wrapper . Won't be able to plot.
>  INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
>  Welcome to Scapy (2.3.1)
>  >>>
>Let me know if there is something else that would help.
>Billy
>On Tue, Aug 15, 2017 at 4:02 AM, Klement Sekera -X (ksekera - PANTHEON
>TECHNOLOGIES at Cisco) <[1]ksek...@cisco.com> wrote:
> 
>  Hi Billy,
> 
>  I haven't seen this issue yet, but it looks like this is a scapy issue
>  on your box. Scapy is a 3rd party library which we use in the test
>  framework. What is the exact version of your OS etc?
> 
>  Thanks,
>  Klement
> 
>  Quoting Billy McFall (2017-08-14 21:30:35)
>  >    I am trying to run "make test" on a CentOS bare metal server. I'm
>  getting
>  >    "Exception: Illegal syntax for IP address". What do I need to
>  >    setup/configure on my server before running "make test"?
>  >    Thanks,
>  >    Billy McFall
>  >    $ make test V=2
>  >    make -C /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root
>  >    PLATFORM=vpp TAG=vpp vpp-install
>  >    make[1]: Entering directory
>  >    `/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
>  >     Arch for platform 'vpp' is native 
>  >     Finding source for dpdk 
>  >     Makefile fragment found in
>  >   
>  
> /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/[1][2]dpdk.mk
>  >    
>  >     Source found in
>  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/dpdk 
>  >     Arch for platform 'vpp' is native 
>  >     Finding source for vpp 
>  >     Makefile fragment found in
>  >   
>  
> /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/[2][3]vpp.mk
>  >    
>  >     Source found in
>  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/src 
>  >     Configuring dpdk: nothing to do 
>  >     Building dpdk: nothing to do 
>  >     Installing dpdk: nothing to do 
>  >     Configuring vpp: nothing to do 
>  >     Building vpp: nothing to do 
>  >     Installing vpp: nothing to do 
>  >    make[1]: Leaving directory
>  >    `/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
>  >    make -C test
>  TEST_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test
>  >   
>  
> VPP_TEST_BUILD_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/build-vpp-native
>  >    VPP_TES
>  >   
>  
> T_BIN=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/bin/vpp
>  >   
>  
> VPP_TEST_PLUGIN_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/i
>  >   
>  
> nstall-vpp-native/vpp/lib/vpp_plugins:/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/vpp_plugins
>  >    VPP_TEST_INSTALL_PATH=/home/bmcfall
>  >    /dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/
>  >   
>  
> LD_LIBRARY_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib/:/home/bm
>  >   
>  
> cfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/
>  >    EXTENDED_TESTS= PYTHON= test
>  >    make[1]: Entering directory
>  >    `/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test'
>  >    Traceback (most recent call last):
>  >      File "sanity_run_vpp.py", line 7, in 
>  >        from framework import VppTestCase, KeepAliveReporter
>  >      File
>  "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/framework.py",
>  >    line 20, in 
>  >        from vpp_pg_interface import VppPGInterface
>  >      File
>  >   
>  "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_pg_interface.py",
>  >    line 8, in 
>  >        from vpp_interface import VppInterface
>  >      File
>  >   
>  "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_interface.py",
>  line
>  >    4, in 
>  >        from util import Host, mk_ll_addr
>  >      File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/util.py",
>  line 7,
>  >    in 
>  >        from scapy.layers.inet6 import in6_mactoifaceid
>  >      File
>  >   
>  
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/layers/inet6.py",
>  >    line 56, in 
>  >        import scapy.route6
>  >    

Re: [vpp-dev] VPP Packet Generator and pg0 IP address

2017-08-15 Thread Michael Borokhovich
Got it. Thanks, Neale!

On Tue, Aug 15, 2017 at 4:45 AM, Neale Ranns (nranns) 
wrote:

> Hi Michael,
>
>
>
> Yes you do have to give the pg interface an IP address before it will
> accept IP packets.
>
> We use pg interfaces in the unit-tests so they have to act like real
> interfaces for us to be able to test all the features.
>
>
>
> Regards,
>
> Neale
>
>
>
>
>
> *From: * on behalf of Michael Borokhovich <
> michael...@gmail.com>
> *Date: *Monday, 14 August 2017 at 23:03
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] VPP Packet Generator and pg0 IP address
>
>
>
> Hi,
>
>
>
> Is it true that in VPP 1707 we have to give IP to the pg0 interface?
>
>
>
> In the previous VPP version (1609), the packet generator worked without IP
> address on pg0, but in 1707 it gives "ip4 adjacency drop" and no packets
> come out. Configuring pg0 with some fake IP worked.
>
>
>
> Thanks,
>
> Michael.
>
>
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Arp resolving with vxlan mesh

2017-08-15 Thread Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco)
Hi vpp devs,

I'm running into problems with arp resolving on our five node setup where I 
have a full vxlan tunnel mesh between the nodes. I have a vhost-user port on 
compute1 and from this VM I'm trying to ping a tap port in linux namespace on 
controller1. All of these are in the same bridge domain. This is what happens:

*The vm sends a broadcast arp request

*The arp request arrives at the tap port on controller1, which answers 
as it should

*Then the arp answer is sent to compute0 instead of compute1 where is 
gets dropped due to this:

o   02:28:07:200496: error-drop
  l2-fwd: Reflection Drop

I'm using vpp-17.10-rc0~157_g0117d24~b2690.x86_64 and this worked fine with 
1704. Any idea what could be the cause or how to debug this further?

Thanks,
Juraj
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] vpp graph dump

2017-08-15 Thread Eyal Lavee

Is there any method to dump the vpp node graph?
I'm looking to understand the supported feature path(s) without needing to 
reverse engineer from the code.

I have seen a previous post from mid 2016 entitled "[vpp-dev] Node graph 
visualization" on such a potential utility, but there do not seem to be any 
follow-ups to this.

Regards,
Eyal.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

2017-08-15 Thread John Lo (loj)
Hi Billy,

The output of “show l2fib” is showing how many MAC entries exist in the L2FIB 
and is not relevant to the size of L2FIB table. The L2FIB table size is not 
configurable. It is a bi-hash table with size set by the following #def’s in 
l2_fib.h and has not changed for quite a while, definitely not between 1704, 
1707 and current master:
/*
* The size of the hash table
*/
#define L2FIB_NUM_BUCKETS (64 * 1024)
#define L2FIB_MEMORY_SIZE (256<<20)

It is interesting to note that at the end of the test run, there is different 
number of MAC entries in the L2FIB. I think this may have to do with a change 
in 1707 where an interface up/down would cause MACs learned on that interface 
to be flushed. So when the interface come back up, the MACs needs to be learned 
again.  With 1704, the stale learned MACs from an interface will remain in 
L2FIB even if the interface is down or deleted unless aging is enabled to 
removed them at the BD aging interval.

Another improvement added in 1707 was a check in the l2-fwd node so when a MAC 
entry is found in L2FIB, its sequence number is checked to make sure it is not 
stale and subject to flushing (such as MAC learned when this interface 
sw_if_index was up but went down, or if this sw_if_index was used, deleted and 
reused). If the MAC is stale, the packet will be flooded instead of making use 
of the stale MAC entry to forward it.

I wonder if the test script for the performance does create/delete interfaces 
or set interface to admin up/down states causing stale MACs be flushed in 1707? 
 With 1704, it may be using stale MAC entries to forward packets rather than 
flooding to learn the MACs again. This can explain the l2-flood and l2-input 
count ratio difference between 1704 and 1707.

When measuring l2-bridg forwarding performance, are you setup to measure the 
forwarding rate in the steady forwarding state?  If all the 10K or 1M flows are 
started at the same time for a particular test, there will be an initial low 
PPS throughput period when all packets needs to be flooded and MACs earned 
before it settle down to a higher steady state PPS forwarding rate. If there is 
interface flap or other events that causes MAC flush, the MAC will needs to be 
learned again. I wonder if the forwarding performance for 10K or 1M flows is 
measure at the steady forwarding state or not.

Above are a few generic comments I can think of, without knowing much details 
about how the tests are setup and measured. Hope it can help to explain the 
different behavior observed between 1704 and 1707.

Regards,
John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Billy McFall
Sent: Monday, August 14, 2017 6:40 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP Performance drop from 17.04 to 17.07

In the last VPP call, I reported some internal Red Hat performance testing was 
showing a significant drop in performance between releases 17.04 to 17.07. This 
with l2-bridge testing - PVP - 0.002% Drop Rate:
   VPP-17.04: 256 Flow 7.8 MP/s 10k Flow 7.3 MP/s 1m Flow 5.2 MP/s
   VPP-17.07: 256 Flow 7.7 MP/s 10k Flow 2.7 MP/s 1m Flow 1.8 MP/s

The performance team re-ran some of the tests for me with some additional data 
collected. Looks like the size of the L2 FIB table was reduced in 17.07. Below 
are the number of entries in the MAC Table after the tests are run:
   17.04:
 show l2fib
 408 l2fib entries
   17.07:
 show l2fib
 1067053 l2fib entries with 1048576 learned (or non-static) entries

This caused more packets to be flooded (see out of 'show node counters' below). 
I looked but couldn't find anything. Is the size of the L2 FIB Table table 
configurable?

Thanks,
Billy McFall


17.04:

show node counters
   CountNode  Reason
:
 313035313l2-inputL2 input packets
555726l2-floodL2 flood packets
:
 310115490l2-inputL2 input packets
824859l2-floodL2 flood packets
:
 313508376l2-inputL2 input packets
   1041961l2-floodL2 flood packets
:
 313691024l2-inputL2 input packets
698968l2-floodL2 flood packets

17.07:

show node counters
   CountNode  Reason
:
  97810569l2-inputL2 input packets
  72557612l2-floodL2 flood packets
:
  97830674l2-inputL2 input packets
  72478802l2-floodL2 flood packets
:
  97714888l2-inputL2 input packets
  71655987l2-floodL2 flood packets
:
  97710374l2-inputL2 input packets
  70058006l2-floodL2 flood packets


--
Billy 

[vpp-dev] memmove fault

2017-08-15 Thread 薛欣颖

Hi,

When I failed to configure a command, then click the up key , there is a 
Segmentation fault(not every time):

Program received signal SIGSEGV, Segmentation fault.
__memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1664
1664../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or 
directory.
(gdb) bt
#0  __memmove_ssse3_back () at 
../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1664
#1  0x77966f56 in unix_cli_line_process_one (cm=0x77ba4960 
, 
um=0x77ba7dc0 , cf=0x7fffb5de5b3c, uf=0x7fffb5de5ae0, 
input=102 'f', 
action=UNIX_CLI_PARSE_ACTION_NOMATCH) at 
/home/vpp/17.07_x64/vpp/build-data/../src/vlib/unix/cli.c:2063
#2  0x77967548 in unix_cli_line_edit (cm=0x77ba4960 
, um=0x77ba7dc0 , 
cf=0x7fffb5de5b3c) at 
/home/vpp/17.07_x64/vpp/build-data/../src/vlib/unix/cli.c:2152
#3  0x77967880 in unix_cli_process_input (cm=0x77ba4960 
, cli_file_index=0)
at /home/vpp/17.07_x64/vpp/build-data/../src/vlib/unix/cli.c:2192
#4  0x7796844b in unix_cli_process (vm=0x77ba7560 
, rt=0x7fffb5e7, f=0x0)
at /home/vpp/17.07_x64/vpp/build-data/../src/vlib/unix/cli.c:2318
#5  0x7792a320 in vlib_process_bootstrap (_a=140736239921232)
at /home/vpp/17.07_x64/vpp/build-data/../src/vlib/main.c:1274
#6  0x7696fd4c in clib_calljmp () at 
/home/vpp/17.07_x64/vpp/build-data/../src/vppinfra/longjmp.S:128
#7  0x7fffb5966820 in ?? ()
#8  0x7792a455 in vlib_process_startup (vm=0x7795e1e9 
, p=0x7fffb5966880, 
f=0xedcb4a35d968b00) at 
/home/vpp/17.07_x64/vpp/build-data/../src/vlib/main.c:1299
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

How should we solve this problem?

Thanks,
xyxue


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Packet Generator and pg0 IP address

2017-08-15 Thread Neale Ranns (nranns)
Hi Michael,

Yes you do have to give the pg interface an IP address before it will accept IP 
packets.
We use pg interfaces in the unit-tests so they have to act like real interfaces 
for us to be able to test all the features.

Regards,
Neale


From:  on behalf of Michael Borokhovich 

Date: Monday, 14 August 2017 at 23:03
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP Packet Generator and pg0 IP address

Hi,

Is it true that in VPP 1707 we have to give IP to the pg0 interface?

In the previous VPP version (1609), the packet generator worked without IP 
address on pg0, but in 1707 it gives "ip4 adjacency drop" and no packets come 
out. Configuring pg0 with some fake IP worked.

Thanks,
Michael.


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

2017-08-15 Thread Neale Ranns (nranns)
VPP does not have MPLS trace-route support. I’d suggest using the packet trace;
   trace add  50
   show trace

/neale

From: Алексей Болдырев 
Date: Monday, 14 August 2017 at 23:52
To: Michael Borokhovich , "Neale Ranns (nranns)" 

Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] MPLS labels question

Скажите пожалуйста, умеет ли vpp отображать процесс в трассировке о надивании и 
снятии MPLS-меток?

Как например тут:
traceroute to kernel.org (198.145.29.83), 30 hops max, 60 byte packets
 1  10.247.1.1 (10.247.1.1)  0.095 ms  0.127 ms  0.122 ms
 2  100.64.0.1 (100.64.0.1)  0.765 ms  0.753 ms  0.893 ms
 3  192.168.192.193 (192.168.192.193)  5.333 ms  5.334 ms  5.329 ms
 4  192.168.192.1 (192.168.192.1)  4.476 ms * *
 5  kiev-r0.w-ix.net (193.106.112.4)  31.109 ms  28.508 ms  28.508 ms
 6  * * *
 7  10ge1-8.core1.vie1.he.net (184.105.222.25)  61.858 ms  61.844 ms  59.284 ms
 8  100ge13-1.core1.par2.he.net (184.105.65.5)  70.435 ms  70.443 ms  70.592 ms
 9  100ge14-1.core1.nyc4.he.net (184.105.81.77)  150.720 ms  150.975 ms  
151.391 ms
10  100ge14-1.core1.tor1.he.net (184.105.80.10) 

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

2017-08-15 Thread Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
Hi Billy,

I haven't seen this issue yet, but it looks like this is a scapy issue
on your box. Scapy is a 3rd party library which we use in the test
framework. What is the exact version of your OS etc?

Thanks,
Klement

Quoting Billy McFall (2017-08-14 21:30:35)
>I am trying to run "make test" on a CentOS bare metal server. I'm getting
>"Exception: Illegal syntax for IP address". What do I need to
>setup/configure on my server before running "make test"?
>Thanks,
>Billy McFall
>$ make test V=2
>make -C /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root
>PLATFORM=vpp TAG=vpp vpp-install
>make[1]: Entering directory
>`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
> Arch for platform 'vpp' is native 
> Finding source for dpdk 
> Makefile fragment found in
>/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/[1]dpdk.mk
>
> Source found in /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/dpdk 
> Arch for platform 'vpp' is native 
> Finding source for vpp 
> Makefile fragment found in
>/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/[2]vpp.mk
>
> Source found in /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/src 
> Configuring dpdk: nothing to do 
> Building dpdk: nothing to do 
> Installing dpdk: nothing to do 
> Configuring vpp: nothing to do 
> Building vpp: nothing to do 
> Installing vpp: nothing to do 
>make[1]: Leaving directory
>`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
>make -C test TEST_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test
>
> VPP_TEST_BUILD_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/build-vpp-native
>VPP_TES
>
> T_BIN=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/bin/vpp
>
> VPP_TEST_PLUGIN_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/i
>
> nstall-vpp-native/vpp/lib/vpp_plugins:/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/vpp_plugins
>VPP_TEST_INSTALL_PATH=/home/bmcfall
>/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/
>
> LD_LIBRARY_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib/:/home/bm
>
> cfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/
>EXTENDED_TESTS= PYTHON= test
>make[1]: Entering directory
>`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test'
>Traceback (most recent call last):
>  File "sanity_run_vpp.py", line 7, in 
>    from framework import VppTestCase, KeepAliveReporter
>  File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/framework.py",
>line 20, in 
>    from vpp_pg_interface import VppPGInterface
>  File
>"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_pg_interface.py",
>line 8, in 
>    from vpp_interface import VppInterface
>  File
>"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_interface.py", line
>4, in 
>    from util import Host, mk_ll_addr
>  File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/util.py", line 7,
>in 
>    from scapy.layers.inet6 import in6_mactoifaceid
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/layers/inet6.py",
>line 56, in 
>    import scapy.route6
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 273, in 
>    conf.route6 = Route6()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 31, in __init__
>    self.resync()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
>line 44, in resync
>    self.routes = read_routes6()
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/arch/linux.py",
>line 283, in read_routes6
>    cset = scapy.utils6.construct_source_candidate_set(d, dp, devaddrs,
>LOOPBACK_NAME)
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
>line 50, in construct_source_candidate_set
>    if in6_isgladdr(addr) or in6_isuladdr(addr):
>  File
>
> "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
>line 708, in in6_isgladdr
>    return in6_isincluded(str, '2000::', 3)
>  File
>
>