Re: [vpp-dev] VPP and KNI related query..

[Narayan, Bindya]

Right after posting this, I realized that KNI support has been removed from 
VPP. The current VPP code does not have the kni patch.

As per the post from Damjan Marion 
(damarion)
  below,

https://www.mail-archive.com/vpp-dev@lists.fd.io/msg02168.html


linux packet interface (af-packet) in the VPP code is what I am looking at.

https://wiki.fd.io/view/VPP/Tutorial_Routing_and_Switching

If anybody has any inputs on if there is an alternate way given that KNI 
support has been removed, please let me know.

Thanks,
Bindya

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Narayan, Bindya
Sent: Wednesday, December 06, 2017 10:10 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP and KNI related query..

Hello all,

Is there any documentation that describes how to enable and use KNI interfaces 
in VPP ?

I am trying to bring VPP up with "kni = 1". However VPP does not start after 
enabling it.

https://wiki.fd.io/view/VPP/Command-line_Arguments

Can someone please point me to some documentation for KNI working with VPP or 
some pointers so I can get this going?
My guess is I am missing some configuration.

Thanks,
Bindya

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

[vpp-dev] VPP and KNI related query..

[Narayan, Bindya]

Hello all,

Is there any documentation that describes how to enable and use KNI interfaces 
in VPP ?

I am trying to bring VPP up with "kni = 1". However VPP does not start after 
enabling it.

https://wiki.fd.io/view/VPP/Command-line_Arguments

Can someone please point me to some documentation for KNI working with VPP or 
some pointers so I can get this going?
My guess is I am missing some configuration.

Thanks,
Bindya

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

[vpp-dev] jenkins job failed

[swarup]

Hi, Can anyone please help me to know the reason behind this jenkins job 
failure?. I found this log. How can I rectify it 
(https://gerrit.fd.io/r/#/c/9735/)? *21:29:03* + echo 'Building using "make verify"'

*21:29:03* Building using "make verify"
*21:29:03* + '[' x == xTrue ']'
*21:29:03* + make UNATTENDED=yes verify
*21:29:04* Loaded plugins: fastestmirror, langpacks
*21:29:35* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:29:35* Trying other mirror.
*21:30:05* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:30:05* Trying other mirror.
*21:30:36* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:30:36* Trying other mirror.
*21:31:06* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:31:06* Trying other mirror.
*21:31:36* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:31:36* Trying other mirror.
*21:32:06* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:32:06* Trying other mirror.
*21:32:36* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:32:36* Trying other mirror.
*21:33:06* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:33:06* Trying other mirror.
*21:33:36* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:33:36* Trying other mirror.
*21:34:06* 
https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: [Errno 12] Timeout onhttps://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

*21:34:06* Trying other mirror.
*21:34:06*
*21:34:06*
*21:34:06*   One of the configured repositories failed (fd.io master branch 
latest merge),
*21:34:06*   and yum doesn't have enough cached data to continue. At this point 
the only
*21:34:06*   safe thing yum can do is fail. There are a few ways to work "fix" 
this:
*21:34:06*
*21:34:06*   1. Contact the upstream for the repository and get them to fix 
the problem.
*21:34:06*
*21:34:06*   2. Reconfigure the baseurl/etc. for the repository, to point 
to a working
*21:34:06*  upstream. This is most often useful if you are using a newer
*21:34:06*  distribution release than is supported by the repository 
(and the
*21:34:06*  packages for the previous distribution release still work).
*21:34:06*
*21:34:06*   3. Run the command with the repository temporarily disabled
*21:34:06*  yum --disablerepo=fdio-master ...
*21:34:06*
*21:34:06*   4. Disable the repository permanently, so yum won't use it by 
default. Yum
*21:34:06*  will then just ignore the repository until you permanently 
enable it
*21:34:06*  again or use --enablerepo for temporary usage:
*21:34:06*
*21:34:06*  yum-config-manager --disable fdio-master
*21:34:06*  or
*21:34:06*  subscription-manager repos --disable=fdio-master
*21:34:06*
*21:34:06*   5. Configure the failing repository to be skipped, if it is 
unavailable.
*21:34:06*  Note 

Re: [vpp-dev] memory issues

[Luke, Chris]

I agree 5g is large, but I do not think this is the FIB. The default heap maxes 
out much sooner than that. Something else is going on.

 

For DPDK, “show dpdk buffer” and otherwise “show physmem”.

 

Chris.

 

From: 薛欣颖 
Date: Tuesday, December 5, 2017 at 20:06
To: Chris Luke , vpp-dev 
Subject: Re: Re: [vpp-dev] memory issues

 

 

Hi Chris，

I see what you mean. I have two other questions: 
1. 200k static routing use 5g memory is also  large , how can I configure it 
use less physical memory?
2. How can I check the packet buffer memory?

BTW, do you have the test similar with 'the memory size 200k static routing 
use'?

Thanks,
Xyxue

 

From: Luke, Chris

Date: 2017-12-05 21:43

To: 薛欣颖; vpp-dev

Subject: Re: [vpp-dev] memory issues

You’re misreading top. “Virt” only means the virtual memory footprint of the 
process. This includes unused heap, shared libraries, anonymous mmap() regions 
etc. “RSS” is the resident-in-memory size. It’s actually using 5G.

 

“show memory” also only shows the heap usage, it does not include packet buffer 
memory.

 

Chris.

 

From:  on behalf of 薛欣颖 
Date: Tuesday, December 5, 2017 at 00:51
To: vpp-dev 
Subject: [vpp-dev] memory issues

 

 

Hi guys，

I am using vpp v18.01-rc0~241-g4c9f2a8.
I configured 200K static routing. When I 'show memory' in VPP, '150+k used'. 
But in my machine ,used almost 15g. After del the static routing ,almost using 
16g memory.
More info is shown below:


VPP# show memory 
Thread 0 vpp_main
heap 0x7fffb58e9000, 1076983 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=0:
heap 0x7fffb58e9000, 1076984 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=1:
heap 0x77ed4000, 2 objects, 128k of 130k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=2:
heap 0x7fffb1e28000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=3:
heap 0x7fffb1628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=4:
heap 0x7fffaf628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=5:
heap 0x7fffaf528000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=6:
heap 0x7fffaf428000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=7:
heap 0x7fffaf328000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=8:
heap 0x7fffaf228000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=9:
heap 0x7fffa7228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=10:
heap 0x7fff9f228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=11:
heap 0x7fff9b228000, 2 objects, 16k of 18k used, 92 free, 0 reclaimed, 1k 
overhead, 65532k capacity
User heap index=12:
heap 0x7fff9b028000, 2 objects, 256k of 258k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=13:
heap 0x7fff9ae28000, 2 objects, 240k of 242k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=14:
heap 0x7fff9ad28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=15:
heap 0x7fff9ac28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=16:
heap 0x7fff9ab28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=17:
heap 0x7fff9a128000, 2 objects, 1k of 3k used, 88 free, 0 reclaimed, 1k 
overhead, 10236k capacity
User heap index=18:
heap 0x7fff9a028000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=19:
heap 0x7fff99f28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=20:
heap 0x7fff99e28000, 2 objects, 2k of 4k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
  
User heap index=21: 

  
heap 0x7fff99d28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=22:
heap 0x7fff99c28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=23:
heap 0x7fff99b28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=24:
heap 0x7fff99a28000, 2 objects, 8k of 10k used, 92 free, 

Re: [vpp-dev] memory issues

[薛欣颖]

Hi Chris，

I see what you mean. I have two other questions: 
1. 200k static routing use 5g memory is also  large , how can I configure it 
use less physical memory?
2. How can I check the packet buffer memory?

BTW, do you have the test similar with 'the memory size 200k static routing 
use'?

Thanks,
Xyxue


 
From: Luke, Chris
Date: 2017-12-05 21:43
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] memory issues
You’re misreading top. “Virt” only means the virtual memory footprint of the 
process. This includes unused heap, shared libraries, anonymous mmap() regions 
etc. “RSS” is the resident-in-memory size. It’s actually using 5G.
 
“show memory” also only shows the heap usage, it does not include packet buffer 
memory.
 
Chris.
 
From:  on behalf of 薛欣颖 
Date: Tuesday, December 5, 2017 at 00:51
To: vpp-dev 
Subject: [vpp-dev] memory issues
 
 
Hi guys，

I am using vpp v18.01-rc0~241-g4c9f2a8.
I configured 200K static routing. When I 'show memory' in VPP, '150+k used'. 
But in my machine ,used almost 15g. After del the static routing ,almost using 
16g memory.
More info is shown below:

VPP# show memory 
Thread 0 vpp_main
heap 0x7fffb58e9000, 1076983 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=0:
heap 0x7fffb58e9000, 1076984 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=1:
heap 0x77ed4000, 2 objects, 128k of 130k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=2:
heap 0x7fffb1e28000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=3:
heap 0x7fffb1628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=4:
heap 0x7fffaf628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=5:
heap 0x7fffaf528000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=6:
heap 0x7fffaf428000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=7:
heap 0x7fffaf328000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=8:
heap 0x7fffaf228000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=9:
heap 0x7fffa7228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=10:
heap 0x7fff9f228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=11:
heap 0x7fff9b228000, 2 objects, 16k of 18k used, 92 free, 0 reclaimed, 1k 
overhead, 65532k capacity
User heap index=12:
heap 0x7fff9b028000, 2 objects, 256k of 258k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=13:
heap 0x7fff9ae28000, 2 objects, 240k of 242k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=14:
heap 0x7fff9ad28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=15:
heap 0x7fff9ac28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=16:
heap 0x7fff9ab28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=17:
heap 0x7fff9a128000, 2 objects, 1k of 3k used, 88 free, 0 reclaimed, 1k 
overhead, 10236k capacity
User heap index=18:
heap 0x7fff9a028000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=19:
heap 0x7fff99f28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=20:
heap 0x7fff99e28000, 2 objects, 2k of 4k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
  
User heap index=21: 

  
heap 0x7fff99d28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=22:
heap 0x7fff99c28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=23:
heap 0x7fff99b28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=24:
heap 0x7fff99a28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=25:
heap 0x7fff99928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=26:
heap 0x7fff97928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=27:
heap 0x7fff95928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=28:

[vpp-dev] NFV with VPP

[Yuliang Li]

Hi all,

If I want to run a VNF chain (e.g., FW, NAT, IDS, VPN gateway...), what is
the normal way of running them with VPP? Do we run each VNF in a
VM/container and use VPP as a software switch, or run each VNF as a node in
the VPP graph? If it is the latter case, is there any open source code
online for these VNF (say, IDS or VPN) that can be plugged into VPP?

Thanks,
-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] i40e in a sorry state?

[Jon Loeliger]

Guys,

I've updated VPP to vpp.x86_64 0:18.01-rc0~405_g7f0d1d3 and when
I enable a interface, I get this love note:

i40e_dev_interrupt_handler(): ICR0: HMC error
Aborted

This used to work, of course.  Some more details below.

Any notions?

Thanks,
jdl


# cat /etc/vpp/startup.conf

unix {
nodaemon
log /tmp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
gid vpp
}

dpdk {
uio-driver igb_uio
}

api-trace {
on
}

api-segment {
gid vpp
}



# /usr/bin/vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development
Kit (DPDK))
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
Deployment on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
load_one_plugin:184: Loaded plugin: router.so (router)
load_one_plugin:184: Loaded plugin: stn_plugin.so (VPP Steals the NIC for
Container integration)
/usr/bin/vpp[4604]: tap_inject_interface_add_del:474:
tap_inject_interface_add_del: Adding interface with hw_if_index 0
/usr/bin/vpp[4604]: tap_inject_is_config_enabled:122:
tap_inject_is_config_enabled: Value of im->flags is 0
/usr/bin/vpp[4604]: tap_inject_interface_add_del:477:
tap_inject_interface_add_del: tap_inject is disabled in config
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/flowprobe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/memif_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/nat_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/pppoe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
/usr/bin/vpp[4604]: tap_inject_is_config_enabled:122:
tap_inject_is_config_enabled: Value of im->flags is 0
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :08:00.0
as host interface enp8s0f0 is up
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :08:00.1
as host interface enp8s0f1 is up
/usr/bin/vpp[4604]: dpdk_bind_devices_to_uio:753: Unsupported PCI device
0x8086:0x0435 found at PCI address :09:00.0
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :0a:00.0
as host interface enp10s0f0 is up
/usr/bin/vpp[4604]: dpdk_config:1216: EAL init args: -c 1 -n 4 --huge-dir
/run/vpp/hugepages --file-prefix vpp -b :08:00.0 -b :08:00.1 -b
:0a:00.0 --master-lcore 0 --socket-mem 64
EAL: No free hugepages reported in hugepages-1048576kB
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
DPDK physical memory layout:
Segment 0: IOVA:0x75c0, len:12582912, virt:0x7f124ec0, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: IOVA:0x76a0, len:2097152, virt:0x7f124e80, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: IOVA:0x43e40, len:2097152, virt:0x7f124e40, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: IOVA:0x43e80, len:33554432, virt:0x7f124c20,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 

Re: [vpp-dev] some files are never compiled

[Dave Barach (dbarach)]

Merged... I’ll clean out some more junk and push another patch... Thanks… Dave

From: Gabriel Ganne [mailto:gabriel.ga...@enea.com]
Sent: Tuesday, December 5, 2017 10:14 AM
To: Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: some files are never compiled


Thanks Dave,



I had submitted a pull-request for the smp files here : 
https://gerrit.fd.io/r/#/c/9730/

Please tell me if I should abandon it and let you do a more complete patch (I 
don't think I can judge for all the mentioned files by myself).



Best regards,



--

Gabriel Ganne


From: Dave Barach (dbarach) >
Sent: Tuesday, December 5, 2017 4:06:09 PM
To: Gabriel Ganne; vpp-dev@lists.fd.io
Subject: RE: some files are never compiled


Dear Gabriel,



The files mentioned below fall into several buckets:



  *   Code samples which might reasonably move to .../extras
  *   Things we’re not using at the moment, but which would take someone a good 
long time to build from scratch.

 *   The simulated annealing driver in vppinfra/anneal.c is a good example.

  *   Debris which should be removed



I’ll push a change-set to remove debris. Most of it is mine anyhow... ()...



Thanks… Dave



From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Gabriel Ganne
Sent: Tuesday, December 5, 2017 9:52 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] some files are never compiled



Hi,



Following a question by Kevin Wang in 
VPP-1066,
 I saw that some files are actually never compiled.

Could some external plugin be using them ?

Can (Should) they be removed ?



As an example, I followed the smp.c, and smp_fido.[ch] files.

They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df 
(reviewed here: 
https://gerrit.fd.io/r/#/c/2273/)
 almost 1.5 year ago.



Here is how I listed them :

for file in $(git find "\.c$"); do

f=`basename $file .c` ;

git grep -q "$f\.c";

if [ $? -eq 1 ] ;  then echo $file ; fi ;

done

src/examples/vlib/plex_test.c
src/tools/g2/mkversion.c
src/vlib/elog_samples.c
src/vlib/parse.c
src/vlib/parse_builtin.c
src/vnet/ethernet/mac_swap.c
src/vnet/fib/fib_entry_src_default.c
src/vnet/ip/ip4_test.c
src/vnet/map/examples/health_check.c
src/vpp/app/sticky_hash.c
src/vppinfra/anneal.c
src/vppinfra/mod_test_hash.c
src/vppinfra/pfhash.c
src/vppinfra/phash.c
src/vppinfra/qhash.c
src/vppinfra/smp.c
src/vppinfra/smp_fifo.c
src/vppinfra/test_pfhash.c
src/vppinfra/test_phash.c
src/vppinfra/test_pool.c
src/vppinfra/test_qhash.c
src/vppinfra/tw_timer_4t_3w_4sl_ov.c
src/vppinfra/unix-kelog.c







--

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

Re: [vpp-dev] Bug?

[Yuliang Li]

That makes sense. Let me check.

On Tue, Dec 5, 2017 at 10:19 AM, John Lo (loj)  wrote:

> In L2 mode, the ethernet interface will be put in promiscuous mode to
> receive all packets on the wire. In L3 mode, it will only receive packets
> whose destination MAC is that of the interface.  What you observe is the
> expected behavior.  -John
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Yuliang Li
> *Sent:* Tuesday, December 05, 2017 9:59 AM
> *To:* Neale Ranns (nranns) 
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Bug?
>
>
>
> Actually there is no packet going to int2.
>
>
>
> When in L3 mode, dpdk-input does not get any packet from int2. But just by
> changing it to L2 mode, dpdk-input gets exactly the same packet from int2
> as from int1.
>
>
>
> At dpdk-input, whether the interface is L2 or L3 should not affect the
> packet it gets. The check (e.g., ethernet-input) is after the dpdk-input.
>
>
>
> That's why I think it may be a bug. (e.g., somehow the memory of the frame
> at int1 and int2 are the same, so the dpdk-input puts the same packet to
> the next node twice. Just my guess, may be wrong).
>
>
>
> On Tue, Dec 5, 2017 at 4:05 AM, Neale Ranns (nranns) 
> wrote:
>
>
>
> By ‘receive’ in this context, I assume you mean it accepts the packet that
> has arrived on the wire. As opposed to the fact that the packet did indeed
> arrive at that interface - clearly it is not the receiving device that
> influences which packets arrive at which interfaces.
>
>
>
> So, let me bounce this back to you. Under what circumstances do L3 and L2
> ports accept a packet?
>
>
>
> Regards,
>
> neale
>
>
>
> *From: * on behalf of Yuliang Li <
> yuliang...@yale.edu>
> *Date: *Tuesday, 5 December 2017 at 04:55
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] Bug?
>
>
>
> Hi,
>
>
>
> I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I feel
> I find a bug.
>
>
>
> I have two physical interfaces TenGigabitEthernet5/0/0 (int1)
> and TenGigabitEthernet5/0/1 (int2).
>
>
>
> Normally, if I send traffic (from another server) to int1, I expect int2
> should NOT receive the traffic. This is true when int2 is in l3 mode.
>
>
>
> However, if I set int2 to l2 mode (e.g., set interface l2 bridge
> TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1
> does. This problem happens no matter int1 is in l2 or l3 mode. I use the
> trace to confirm that int2 receives the same traffic as int1 does.
>
>
>
> Does anyone know this problem?
>
>
>
> Thanks,
>
> --
>
> Yuliang Li
>
> PhD student
>
> Department of Computer Science
>
> Yale University
>
>
>
>
>
> --
>
> Yuliang Li
>
> PhD student
>
> Department of Computer Science
>
> Yale University
>



-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build error when trying to cross-compile vpp

[Dave Barach (dbarach)]

See also “bootstrap.sh...”

$ make V=0 is_build_tool=yes tools-install

Thanks… Dave

From: nikhil ap [mailto:niks3...@gmail.com]
Sent: Tuesday, December 5, 2017 9:11 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

Hi Dave,

I added a file x86_64.mk in .../build-data/plaforms/ with the 
following content:

x86_64_arch = x86_64
x86_64_os = rumprun-netbsd
x86_64_target = x86_64-rumprun-netbsd
x86_64_native_tools = vppapigen
x86_64_uses_dpdk = yes

and in the TLD I did a "make PLATFORM=x86_64 TAG=x86_64_debug bootstrap" but I 
am still seeing that vppapigen is not getting built. Any clues?

Thanks,
Nikhil


On Tue, Dec 5, 2017 at 7:05 PM, Dave Barach (dbarach) 
> wrote:
Dear Nikhil,

The first step in adding a new platform: construct 
.../build-data/plaforms/xxx.mk. There are several examples.

Note the rule:

xxx_native_tools = vppapigen

This rule builds the missing build-host tool.

Then:

“make PLATFORM=xxx TAG=xxx_debug vpp-install” or similar.

Caveat: the main Makefile “.../build-root/Makefile” is non-trivial.

In the past, we’ve used it to self-compile full toolchains, and to use the 
resulting toolchains to cross-compile embedded Linux images with squashfs / 
unionfs disk images.

All of the mechanisms are there to do interesting things, but since we seldom 
do those things anymore you can expect a certain amount of trouble.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of nikhil ap
Sent: Tuesday, December 5, 2017 6:05 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

After a bit more digging around the make file, I did this:

 make PLATFORM=x86_64 x86_64_os=rumprun-netbsd bootstrap

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-rumprun-netbsd
checking whether we are cross compiling... yes

However, I am still seeing this error:

checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...
Makefile:635: recipe for target 'tools-configure' failed
make[1]: *** [tools-configure] Error 1

What is the issue?

On Tue, Dec 5, 2017 at 3:55 PM, nikhil ap 
> wrote:
Hi All,

I am trying to cross-compile vpp. The make doesn't expose a way to pass the 
--host parameter required to configure and build using cross compilation.

Initially, I did the following:

CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error

If you meant to cross compile, use `--host'.
See `config.log' for more details

As a work-around based on the config.log, I did this following

/src/configure (Stripped other output ) --build=x86_64-linux-gnu 
--host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu

However,  I saw the following error:
checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...

Is there a way to cleanly cross-compile?


--
Regards,
Nikhil



--
Regards,
Nikhil



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

Re: [vpp-dev] Bug?

[John Lo (loj)]

In L2 mode, the ethernet interface will be put in promiscuous mode to receive 
all packets on the wire. In L3 mode, it will only receive packets whose 
destination MAC is that of the interface.  What you observe is the expected 
behavior.  -John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Yuliang Li
Sent: Tuesday, December 05, 2017 9:59 AM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Bug?

Actually there is no packet going to int2.

When in L3 mode, dpdk-input does not get any packet from int2. But just by 
changing it to L2 mode, dpdk-input gets exactly the same packet from int2 as 
from int1.

At dpdk-input, whether the interface is L2 or L3 should not affect the packet 
it gets. The check (e.g., ethernet-input) is after the dpdk-input.

That's why I think it may be a bug. (e.g., somehow the memory of the frame at 
int1 and int2 are the same, so the dpdk-input puts the same packet to the next 
node twice. Just my guess, may be wrong).

On Tue, Dec 5, 2017 at 4:05 AM, Neale Ranns (nranns) 
> wrote:

By ‘receive’ in this context, I assume you mean it accepts the packet that has 
arrived on the wire. As opposed to the fact that the packet did indeed arrive 
at that interface - clearly it is not the receiving device that influences 
which packets arrive at which interfaces.

So, let me bounce this back to you. Under what circumstances do L3 and L2 ports 
accept a packet?

Regards,
neale

From: > on 
behalf of Yuliang Li >
Date: Tuesday, 5 December 2017 at 04:55
To: "vpp-dev@lists.fd.io" 
>
Subject: [vpp-dev] Bug?

Hi,

I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I feel I find 
a bug.

I have two physical interfaces TenGigabitEthernet5/0/0 (int1) and 
TenGigabitEthernet5/0/1 (int2).

Normally, if I send traffic (from another server) to int1, I expect int2 should 
NOT receive the traffic. This is true when int2 is in l3 mode.

However, if I set int2 to l2 mode (e.g., set interface l2 bridge 
TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1 does. 
This problem happens no matter int1 is in l2 or l3 mode. I use the trace to 
confirm that int2 receives the same traffic as int1 does.

Does anyone know this problem?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University



--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] some files are never compiled

[Gabriel Ganne]

Thanks Dave,


I had submitted a pull-request for the smp files here : 
https://gerrit.fd.io/r/#/c/9730/

Please tell me if I should abandon it and let you do a more complete patch (I 
don't think I can judge for all the mentioned files by myself).


Best regards,


--

Gabriel Ganne


From: Dave Barach (dbarach) 
Sent: Tuesday, December 5, 2017 4:06:09 PM
To: Gabriel Ganne; vpp-dev@lists.fd.io
Subject: RE: some files are never compiled


Dear Gabriel,



The files mentioned below fall into several buckets:



  *   Code samples which might reasonably move to .../extras
  *   Things we’re not using at the moment, but which would take someone a good 
long time to build from scratch.
 *   The simulated annealing driver in vppinfra/anneal.c is a good example.
  *   Debris which should be removed



I’ll push a change-set to remove debris. Most of it is mine anyhow... ()...



Thanks… Dave



From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Gabriel Ganne
Sent: Tuesday, December 5, 2017 9:52 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] some files are never compiled



Hi,



Following a question by Kevin Wang in 
VPP-1066,
 I saw that some files are actually never compiled.

Could some external plugin be using them ?

Can (Should) they be removed ?



As an example, I followed the smp.c, and smp_fido.[ch] files.

They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df 
(reviewed here: 
https://gerrit.fd.io/r/#/c/2273/)
 almost 1.5 year ago.



Here is how I listed them :

for file in $(git find "\.c$"); do

f=`basename $file .c` ;

git grep -q "$f\.c";

if [ $? -eq 1 ] ;  then echo $file ; fi ;

done

src/examples/vlib/plex_test.c
src/tools/g2/mkversion.c
src/vlib/elog_samples.c
src/vlib/parse.c
src/vlib/parse_builtin.c
src/vnet/ethernet/mac_swap.c
src/vnet/fib/fib_entry_src_default.c
src/vnet/ip/ip4_test.c
src/vnet/map/examples/health_check.c
src/vpp/app/sticky_hash.c
src/vppinfra/anneal.c
src/vppinfra/mod_test_hash.c
src/vppinfra/pfhash.c
src/vppinfra/phash.c
src/vppinfra/qhash.c
src/vppinfra/smp.c
src/vppinfra/smp_fifo.c
src/vppinfra/test_pfhash.c
src/vppinfra/test_phash.c
src/vppinfra/test_pool.c
src/vppinfra/test_qhash.c
src/vppinfra/tw_timer_4t_3w_4sl_ov.c
src/vppinfra/unix-kelog.c







--

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

Re: [vpp-dev] some files are never compiled

[Dave Barach (dbarach)]

Dear Gabriel,

The files mentioned below fall into several buckets:


  *   Code samples which might reasonably move to .../extras
  *   Things we’re not using at the moment, but which would take someone a good 
long time to build from scratch.
 *   The simulated annealing driver in vppinfra/anneal.c is a good example.
  *   Debris which should be removed

I’ll push a change-set to remove debris. Most of it is mine anyhow... ()...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Gabriel Ganne
Sent: Tuesday, December 5, 2017 9:52 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] some files are never compiled


Hi,



Following a question by Kevin Wang in 
VPP-1066, I saw that some files are 
actually never compiled.

Could some external plugin be using them ?

Can (Should) they be removed ?



As an example, I followed the smp.c, and smp_fido.[ch] files.
They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df 
(reviewed here: https://gerrit.fd.io/r/#/c/2273/) almost 1.5 year ago.



Here is how I listed them :

for file in $(git find "\.c$"); do

f=`basename $file .c` ;

git grep -q "$f\.c";

if [ $? -eq 1 ] ;  then echo $file ; fi ;

done
src/examples/vlib/plex_test.c
src/tools/g2/mkversion.c
src/vlib/elog_samples.c
src/vlib/parse.c
src/vlib/parse_builtin.c
src/vnet/ethernet/mac_swap.c
src/vnet/fib/fib_entry_src_default.c
src/vnet/ip/ip4_test.c
src/vnet/map/examples/health_check.c
src/vpp/app/sticky_hash.c
src/vppinfra/anneal.c
src/vppinfra/mod_test_hash.c
src/vppinfra/pfhash.c
src/vppinfra/phash.c
src/vppinfra/qhash.c
src/vppinfra/smp.c
src/vppinfra/smp_fifo.c
src/vppinfra/test_pfhash.c
src/vppinfra/test_phash.c
src/vppinfra/test_pool.c
src/vppinfra/test_qhash.c
src/vppinfra/tw_timer_4t_3w_4sl_ov.c
src/vppinfra/unix-kelog.c






--

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

Re: [vpp-dev] Bug?

[Yuliang Li]

Actually there is no packet going to int2.

When in L3 mode, dpdk-input does not get any packet from int2. But just by
changing it to L2 mode, dpdk-input gets exactly the same packet from int2
as from int1.

At dpdk-input, whether the interface is L2 or L3 should not affect the
packet it gets. The check (e.g., ethernet-input) is after the dpdk-input.

That's why I think it may be a bug. (e.g., somehow the memory of the frame
at int1 and int2 are the same, so the dpdk-input puts the same packet to
the next node twice. Just my guess, may be wrong).

On Tue, Dec 5, 2017 at 4:05 AM, Neale Ranns (nranns) 
wrote:

>
>
> By ‘receive’ in this context, I assume you mean it accepts the packet that
> has arrived on the wire. As opposed to the fact that the packet did indeed
> arrive at that interface - clearly it is not the receiving device that
> influences which packets arrive at which interfaces.
>
>
>
> So, let me bounce this back to you. Under what circumstances do L3 and L2
> ports accept a packet?
>
>
>
> Regards,
>
> neale
>
>
>
> *From: * on behalf of Yuliang Li <
> yuliang...@yale.edu>
> *Date: *Tuesday, 5 December 2017 at 04:55
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] Bug?
>
>
>
> Hi,
>
>
>
> I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I feel
> I find a bug.
>
>
>
> I have two physical interfaces TenGigabitEthernet5/0/0 (int1)
> and TenGigabitEthernet5/0/1 (int2).
>
>
>
> Normally, if I send traffic (from another server) to int1, I expect int2
> should NOT receive the traffic. This is true when int2 is in l3 mode.
>
>
>
> However, if I set int2 to l2 mode (e.g., set interface l2 bridge
> TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1
> does. This problem happens no matter int1 is in l2 or l3 mode. I use the
> trace to confirm that int2 receives the same traffic as int1 does.
>
>
>
> Does anyone know this problem?
>
>
>
> Thanks,
>
> --
>
> Yuliang Li
>
> PhD student
>
> Department of Computer Science
>
> Yale University
>
>


-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] some files are never compiled

[Gabriel Ganne]

Hi,


Following a question by Kevin Wang in 
VPP-1066, I saw that some files are 
actually never compiled.

Could some external plugin be using them ?

Can (Should) they be removed ?


As an example, I followed the smp.c, and smp_fido.[ch] files.

They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df 
(reviewed here: https://gerrit.fd.io/r/#/c/2273/) almost 1.5 year ago.


Here is how I listed them :

for file in $(git find "\.c$"); do

f=`basename $file .c` ;

git grep -q "$f\.c";

if [ $? -eq 1 ] ;  then echo $file ; fi ;

done

src/examples/vlib/plex_test.c
src/tools/g2/mkversion.c
src/vlib/elog_samples.c
src/vlib/parse.c
src/vlib/parse_builtin.c
src/vnet/ethernet/mac_swap.c
src/vnet/fib/fib_entry_src_default.c
src/vnet/ip/ip4_test.c
src/vnet/map/examples/health_check.c
src/vpp/app/sticky_hash.c
src/vppinfra/anneal.c
src/vppinfra/mod_test_hash.c
src/vppinfra/pfhash.c
src/vppinfra/phash.c
src/vppinfra/qhash.c
src/vppinfra/smp.c
src/vppinfra/smp_fifo.c
src/vppinfra/test_pfhash.c
src/vppinfra/test_phash.c
src/vppinfra/test_pool.c
src/vppinfra/test_qhash.c
src/vppinfra/tw_timer_4t_3w_4sl_ov.c
src/vppinfra/unix-kelog.c




--

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

Re: [vpp-dev] vpp-api-python depends on vpp (= 17.10-9~gd594711); however: Version of vpp on system is 17.10-release.

[Pradeep Patel (pradpate)]

Please try  ‘sudo apt-get install –f’

On 12/5/17, 6:38 AM, "vpp-dev-boun...@lists.fd.io on behalf of Pradeep Patel 
(pradpate)"  wrote:

Trying running ‘apt install -f’ 

On 12/5/17, 5:38 AM, "vpp-dev-boun...@lists.fd.io on behalf of Ole Troan" 
 wrote:

Mirzaei,

> I want to build vpp to integrate it with honeycomb according to this 
url, but I failed in the at this command:
> 
> $sudo dpkg -i *.deb
> 
> the error :
> 

> (Reading database ... 75373 files and directories currently 
installed.)
> Preparing to unpack vpp-api-python_17.10-9~gd594711_amd64.deb ...
> Unpacking vpp-api-python (17.10-9~gd594711) over (17.10-9~gd594711) 
...
> dpkg: dependency problems prevent configuration of vpp-api-python:
>  vpp-api-python depends on vpp (= 17.10-9~gd594711); however:
>  Version of vpp on system is 17.10-release.
> 
> dpkg: error processing package vpp-api-python (--install):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  vpp-api-python
> 
***
> 
> Can you please help me to fix this problem?

You might have the vpp 17.10-release debian package installed already. 
Try to remove that first.

Best regards,
Ole


___
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

Re: [vpp-dev] vpp-api-python depends on vpp (= 17.10-9~gd594711); however: Version of vpp on system is 17.10-release.

[Pradeep Patel (pradpate)]

Trying running ‘apt install -f’ 

On 12/5/17, 5:38 AM, "vpp-dev-boun...@lists.fd.io on behalf of Ole Troan" 
 wrote:

Mirzaei,

> I want to build vpp to integrate it with honeycomb according to this url, 
but I failed in the at this command:
> 
> $sudo dpkg -i *.deb
> 
> the error :
> 

> (Reading database ... 75373 files and directories currently installed.)
> Preparing to unpack vpp-api-python_17.10-9~gd594711_amd64.deb ...
> Unpacking vpp-api-python (17.10-9~gd594711) over (17.10-9~gd594711) ...
> dpkg: dependency problems prevent configuration of vpp-api-python:
>  vpp-api-python depends on vpp (= 17.10-9~gd594711); however:
>  Version of vpp on system is 17.10-release.
> 
> dpkg: error processing package vpp-api-python (--install):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  vpp-api-python
> 
***
> 
> Can you please help me to fix this problem?

You might have the vpp 17.10-release debian package installed already. Try 
to remove that first.

Best regards,
Ole


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

Re: [vpp-dev] Question about Jira

[Luke, Chris]

Replying to an individual who sent me a message on IRC, but was not online when 
I went to reply:

 

    Hi Sir, sorry to bother you. I have some confusion. Is it required to have 
JIRA task for

    each gerrit review? I am new to FD.io, I am not sure If I can post such 
question in

    community mail or not.

 

Short answer: no, we don't typically require that except for bugs, and we only 
really enforce that close to release time. All patches welcome, and we’ll be 
friendly about asking for a Jira ticket if necessary.

 

Cheers,

Chris.

 



smime.p7s
Description: S/MIME cryptographic signature
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build error when trying to cross-compile vpp

[nikhil ap]

Hi Dave,

I added a file x86_64.mk in .../build-data/plaforms/ with the following
content:

x86_64_arch = x86_64
x86_64_os = rumprun-netbsd
x86_64_target = x86_64-rumprun-netbsd
x86_64_native_tools = vppapigen
x86_64_uses_dpdk = yes

and in the TLD I did a "make PLATFORM=x86_64 TAG=x86_64_debug bootstrap"
but I am still seeing that vppapigen is not getting built. Any clues?

Thanks,
Nikhil


On Tue, Dec 5, 2017 at 7:05 PM, Dave Barach (dbarach) 
wrote:

> Dear Nikhil,
>
>
>
> The first step in adding a new platform: construct .../build-data/plaforms/
> xxx.mk. There are several examples.
>
>
>
> Note the rule:
>
>
>
> xxx_native_tools = vppapigen
>
>
>
> This rule builds the missing build-host tool.
>
>
>
> Then:
>
>
>
> “make PLATFORM=xxx TAG=xxx_debug vpp-install” or similar.
>
>
>
> Caveat: the main Makefile “.../build-root/Makefile” is non-trivial.
>
>
>
> In the past, we’ve used it to self-compile full toolchains, and to use the
> resulting toolchains to cross-compile embedded Linux images with squashfs /
> unionfs disk images.
>
>
>
> All of the mechanisms are there to do interesting things, but since we
> seldom do those things anymore you can expect a certain amount of trouble.
>
>
>
> Thanks… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *nikhil ap
> *Sent:* Tuesday, December 5, 2017 6:05 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Build error when trying to cross-compile vpp
>
>
>
> After a bit more digging around the make file, I did this:
>
>
>
>  make PLATFORM=x86_64 x86_64_os=rumprun-netbsd bootstrap
>
>
>
> checking build system type... x86_64-pc-linux-gnu
>
> checking host system type... x86_64-rumprun-netbsd
>
> checking whether we are cross compiling... yes
>
>
>
> However, I am still seeing this error:
>
>
>
> checking for vppapigen... no
>
> configure: error: Externaly built vppapigen is needed when
> cross-compiling...
>
> Makefile:635: recipe for target 'tools-configure' failed
>
> make[1]: *** [tools-configure] Error 1
>
>
>
> What is the issue?
>
>
>
> On Tue, Dec 5, 2017 at 3:55 PM, nikhil ap  wrote:
>
> Hi All,
>
>
>
> I am trying to cross-compile vpp. The make doesn't expose a way to pass
> the --host parameter required to configure and build using cross
> compilation.
>
>
>
> Initially, I did the following:
>
>
>
> CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error
>
>
>
> *If you meant to cross compile, use `--host'.*
>
> *See `config.log' for more details*
>
>
>
> As a work-around based on the config.log, I did this following
>
>
>
> /src/configure (Stripped other output ) --build=x86_64-linux-gnu
> --host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu
>
>
>
> However,  I saw the following error:
>
> checking for vppapigen... no
>
> configure: error: Externaly built vppapigen is needed when
> cross-compiling...
>
>
>
> Is there a way to cleanly cross-compile?
>
>
>
>
> --
>
> Regards,
>
> Nikhil
>
>
>
>
>
> --
>
> Regards,
>
> Nikhil
>



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

Re: [vpp-dev] memory issues

[Luke, Chris]

You’re misreading top. “Virt” only means the virtual memory footprint of the 
process. This includes unused heap, shared libraries, anonymous mmap() regions 
etc. “RSS” is the resident-in-memory size. It’s actually using 5G.

 

“show memory” also only shows the heap usage, it does not include packet buffer 
memory.

 

Chris.

 

From:  on behalf of 薛欣颖 
Date: Tuesday, December 5, 2017 at 00:51
To: vpp-dev 
Subject: [vpp-dev] memory issues

 

 

Hi guys，

I am using vpp v18.01-rc0~241-g4c9f2a8.
I configured 200K static routing. When I 'show memory' in VPP, '150+k used'. 
But in my machine ,used almost 15g. After del the static routing ,almost using 
16g memory.
More info is shown below:


VPP# show memory 
Thread 0 vpp_main
heap 0x7fffb58e9000, 1076983 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=0:
heap 0x7fffb58e9000, 1076984 objects, 110755k of 151671k used, 15386k free, 
13352k reclaimed, 16829k overhead, 1048572k capacity
User heap index=1:
heap 0x77ed4000, 2 objects, 128k of 130k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=2:
heap 0x7fffb1e28000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=3:
heap 0x7fffb1628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 8188k capacity
User heap index=4:
heap 0x7fffaf628000, 2 objects, 512k of 514k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=5:
heap 0x7fffaf528000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=6:
heap 0x7fffaf428000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=7:
heap 0x7fffaf328000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=8:
heap 0x7fffaf228000, 2 objects, 120k of 122k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=9:
heap 0x7fffa7228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=10:
heap 0x7fff9f228000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 131068k capacity
User heap index=11:
heap 0x7fff9b228000, 2 objects, 16k of 18k used, 92 free, 0 reclaimed, 1k 
overhead, 65532k capacity
User heap index=12:
heap 0x7fff9b028000, 2 objects, 256k of 258k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=13:
heap 0x7fff9ae28000, 2 objects, 240k of 242k used, 92 free, 0 reclaimed, 1k 
overhead, 2044k capacity
User heap index=14:
heap 0x7fff9ad28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=15:
heap 0x7fff9ac28000, 5 objects, 8k of 10k used, 168 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=16:
heap 0x7fff9ab28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=17:
heap 0x7fff9a128000, 2 objects, 1k of 3k used, 88 free, 0 reclaimed, 1k 
overhead, 10236k capacity
User heap index=18:
heap 0x7fff9a028000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=19:
heap 0x7fff99f28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=20:
heap 0x7fff99e28000, 2 objects, 2k of 4k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
  
User heap index=21: 

  
heap 0x7fff99d28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=22:
heap 0x7fff99c28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=23:
heap 0x7fff99b28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=24:
heap 0x7fff99a28000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=25:
heap 0x7fff99928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 1020k capacity
User heap index=26:
heap 0x7fff97928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=27:
heap 0x7fff95928000, 2 objects, 8k of 10k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=28:
heap 0x7fff94928000, 2 objects, 1k of 3k used, 92 free, 0 reclaimed, 1k 
overhead, 16380k capacity
User heap index=29:
heap 0x7fff92928000, 2 objects, 128k of 130k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=30:
heap 0x7fff90928000, 2 objects, 128k of 130k used, 92 free, 0 reclaimed, 1k 
overhead, 32764k capacity
User heap index=31:
heap 0x7fff8f928000, 2 objects, 8k of 

Re: [vpp-dev] vpp-api-python depends on vpp (= 17.10-9~gd594711); however: Version of vpp on system is 17.10-release.

[Ole Troan]

Mirzaei,

> I want to build vpp to integrate it with honeycomb according to this url, but 
> I failed in the at this command:
> 
> $sudo dpkg -i *.deb
> 
> the error :
> 
> (Reading database ... 75373 files and directories currently installed.)
> Preparing to unpack vpp-api-python_17.10-9~gd594711_amd64.deb ...
> Unpacking vpp-api-python (17.10-9~gd594711) over (17.10-9~gd594711) ...
> dpkg: dependency problems prevent configuration of vpp-api-python:
>  vpp-api-python depends on vpp (= 17.10-9~gd594711); however:
>  Version of vpp on system is 17.10-release.
> 
> dpkg: error processing package vpp-api-python (--install):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  vpp-api-python
> ***
> 
> Can you please help me to fix this problem?

You might have the vpp 17.10-release debian package installed already. Try to 
remove that first.

Best regards,
Ole


signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP high level working flowchart

[Luke, Chris]

I may have missed other responses, but the single biggest issue with your flow 
diagram is that there is no Linux network stack interaction unless an agent 
explicitly configures a logical network interface, or other mechanism, that 
does.

 

VPP provides a completely independent packet data-plane which only interacts 
with Linux as a mechanism to run the code; networking with Linux is completely 
optional.

 

Chris.

 

From:  on behalf of Holoo Gulakh 

Date: Monday, December 4, 2017 at 01:28
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP high level working flowchart

 

Hi,

According to my researches around VPP and its workflow, I have prepared a 
flowchart showing VPP's workflow.

 

This flowchart says that all ingress packet to interfaces handled by VPP are 
sent to VPP without Linux network stack intervention. afterward based on the 
packet type/destination one of the flows goes on.

 

Is this flowchart describing VPP's workflow correctly?? (it might be helpful if 
you add more details to it if it's correct OR otherwise correct it if it's 
wrong)

 

thanks in advace



smime.p7s
Description: S/MIME cryptographic signature
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build error when trying to cross-compile vpp

[Dave Barach (dbarach)]

Dear Nikhil,

The first step in adding a new platform: construct 
.../build-data/plaforms/xxx.mk. There are several examples.

Note the rule:

xxx_native_tools = vppapigen

This rule builds the missing build-host tool.

Then:

“make PLATFORM=xxx TAG=xxx_debug vpp-install” or similar.

Caveat: the main Makefile “.../build-root/Makefile” is non-trivial.

In the past, we’ve used it to self-compile full toolchains, and to use the 
resulting toolchains to cross-compile embedded Linux images with squashfs / 
unionfs disk images.

All of the mechanisms are there to do interesting things, but since we seldom 
do those things anymore you can expect a certain amount of trouble.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of nikhil ap
Sent: Tuesday, December 5, 2017 6:05 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

After a bit more digging around the make file, I did this:

 make PLATFORM=x86_64 x86_64_os=rumprun-netbsd bootstrap

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-rumprun-netbsd
checking whether we are cross compiling... yes

However, I am still seeing this error:

checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...
Makefile:635: recipe for target 'tools-configure' failed
make[1]: *** [tools-configure] Error 1

What is the issue?

On Tue, Dec 5, 2017 at 3:55 PM, nikhil ap 
> wrote:
Hi All,

I am trying to cross-compile vpp. The make doesn't expose a way to pass the 
--host parameter required to configure and build using cross compilation.

Initially, I did the following:

CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error

If you meant to cross compile, use `--host'.
See `config.log' for more details

As a work-around based on the config.log, I did this following

/src/configure (Stripped other output ) --build=x86_64-linux-gnu 
--host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu

However,  I saw the following error:
checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...

Is there a way to cleanly cross-compile?


--
Regards,
Nikhil



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

[vpp-dev] vpp-api-python depends on vpp (= 17.10-9~gd594711); however: Version of vpp on system is 17.10-release.

[mirzaei.reza]

Hi 

I want to build vpp to integrate it with honeycomb according to this url
[1], but I failed in the at this command:

$SUDO DPKG -I *.DEB

THE ERROR :

(Reading database ... 75373 files and directories currently installed.)
Preparing to unpack vpp-api-python_17.10-9~gd594711_amd64.deb ...
Unpacking vpp-api-python (17.10-9~gd594711) over (17.10-9~gd594711) ...
dpkg: dependency problems prevent configuration of vpp-api-python:
_ VPP-API-PYTHON DEPENDS ON VPP (= 17.10-9~GD594711); HOWEVER:_
_ VERSION OF VPP ON SYSTEM IS 17.10-RELEASE._

dpkg: error processing package vpp-api-python (--install):
 dependency problems - leaving unconfigured
_ERRORS WERE ENCOUNTERED WHILE PROCESSING:_
_ VPP-API-PYTHON_
***

Can you please help me to fix this problem?
Best regards
Reza
 

Links:
--
[1]
https://docs.fd.io/hc2vpp/1.17.10/hc2vpp-parent/release-notes-aggregator/install_manual_build.html___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Bug?

[Kinsella, Ray]

I imagine the bridge ports are being flooded looking for the final 
destination.



Ray K


On 05/12/2017 03:55, Yuliang Li wrote:

Hi,

I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I 
feel I find a bug.


I have two physical interfaces TenGigabitEthernet5/0/0 (int1) 
and TenGigabitEthernet5/0/1 (int2).


Normally, if I send traffic (from another server) to int1, I expect 
int2 should NOT receive the traffic. This is true when int2 is in l3 mode.


However, if I set int2 to l2 mode (e.g., set interface l2 bridge 
TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1 
does. This problem happens no matter int1 is in l2 or l3 mode. I use 
the trace to confirm that int2 receives the same traffic as int1 does.


Does anyone know this problem?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University


___
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] Build error when trying to cross-compile vpp

[nikhil ap]

Hi All,

I am trying to cross-compile vpp. The make doesn't expose a way to pass the
--host parameter required to configure and build using cross compilation.

Initially, I did the following:

CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error

*If you meant to cross compile, use `--host'.*
*See `config.log' for more details*

As a work-around based on the config.log, I did this following

/src/configure (Stripped other output ) --build=x86_64-linux-gnu
--host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu

However,  I saw the following error:
checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when
cross-compiling...

Is there a way to cleanly cross-compile?


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

Re: [vpp-dev] Build error when trying to cross-compile vpp

[nikhil ap]

After a bit more digging around the make file, I did this:

 make PLATFORM=x86_64 x86_64_os=rumprun-netbsd bootstrap

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-rumprun-netbsd
checking whether we are cross compiling... yes

However, I am still seeing this error:

checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when
cross-compiling...
Makefile:635: recipe for target 'tools-configure' failed
make[1]: *** [tools-configure] Error 1

What is the issue?

On Tue, Dec 5, 2017 at 3:55 PM, nikhil ap  wrote:

> Hi All,
>
> I am trying to cross-compile vpp. The make doesn't expose a way to pass
> the --host parameter required to configure and build using cross
> compilation.
>
> Initially, I did the following:
>
> CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error
>
> *If you meant to cross compile, use `--host'.*
> *See `config.log' for more details*
>
> As a work-around based on the config.log, I did this following
>
> /src/configure (Stripped other output ) --build=x86_64-linux-gnu
> --host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu
>
> However,  I saw the following error:
> checking for vppapigen... no
> configure: error: Externaly built vppapigen is needed when
> cross-compiling...
>
> Is there a way to cleanly cross-compile?
>
>
> --
> Regards,
> Nikhil
>



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

Re: [vpp-dev] Bug?

[Neale Ranns (nranns)]

By ‘receive’ in this context, I assume you mean it accepts the packet that has 
arrived on the wire. As opposed to the fact that the packet did indeed arrive 
at that interface - clearly it is not the receiving device that influences 
which packets arrive at which interfaces.

So, let me bounce this back to you. Under what circumstances do L3 and L2 ports 
accept a packet?

Regards,
neale

From:  on behalf of Yuliang Li 

Date: Tuesday, 5 December 2017 at 04:55
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Bug?

Hi,

I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I feel I find 
a bug.

I have two physical interfaces TenGigabitEthernet5/0/0 (int1) and 
TenGigabitEthernet5/0/1 (int2).

Normally, if I send traffic (from another server) to int1, I expect int2 should 
NOT receive the traffic. This is true when int2 is in l3 mode.

However, if I set int2 to l2 mode (e.g., set interface l2 bridge 
TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1 does. 
This problem happens no matter int1 is in l2 or l3 mode. I use the trace to 
confirm that int2 receives the same traffic as int1 does.

Does anyone know this problem?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev