Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07
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
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
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
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
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
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
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
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
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
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
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
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
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
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 > >