date:20170308

Re: [vpp-dev] Missing lib pneum during build?

2017-03-08 Thread otroan

Jon,


> On 8 Mar 2017, at 01:34, Jon Loeliger  wrote:
> 
> On Mon, Mar 6, 2017 at 2:57 PM, Jon Loeliger  wrote:
> 
> Hi Billy,
> 
> S, despite the Peanut Gallery, I'm not yet crazy... :-)
> 
> Now all we have to do is find the missing dependency in a Makefile! :-)
> 
> Thanks,
> jdl
> 
> I may not be crazy (yet), but I am in a vacuum.
> 
> OK, as a review, here is the error message:
> 
> running build_ext
> building 'vpp_api' extension
> creating build
> creating build/temp.linux-x86_64-2.7
> creating build/temp.linux-x86_64-2.7/vpp_papi
> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv 
> -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
> -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC 
> -I/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include/
>  -I/usr/include/python2.7 -c vpp_papi/pneum_wrap.c -o 
> build/temp.linux-x86_64-2.7/vpp_papi/pneum_wrap.o
> creating build/lib.linux-x86_64-2.7
> gcc -pthread -shared -Wl,-z,relro 
> build/temp.linux-x86_64-2.7/vpp_papi/pneum_wrap.o 
> -L/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64
>  -L. -lpneum -lpython2.7 -o build/lib.linux-x86_64-2.7/vpp_api.so
> /bin/ld: cannot find -lpneum
> collect2: error: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> make[7]: *** [install-exec-local] Error 1
> 
> 
> So, let's pick on install-exec-local.  That is from 
> src/vpp-api/python/Makefile.am:
> 
> install-exec-local:
> cd $(srcdir);   \
> mkdir -p $(pythondir);  \
> mkdir -p $(pyexecdir);  \
> PYTHONUSERBASE=$(prefix)\
> python setup.py build_ext -L $(libdir)  \
>   -I $(prefix)/include/ install --user
> 
> And the setup.py in that directory says:
> 
> setup (name = 'vpp_papi',
>version = '1.3',
>description = 'VPP Python binding',
>author = 'Ole Troan',
>author_email = 'o...@cisco.com',
>test_suite = 'tests',
>packages=['vpp_papi'],
>ext_modules = [
>Extension(
>'vpp_api',
>sources = ['vpp_papi/pneum_wrap.c'],
>libraries = ['pneum'],
>)],
>long_description = '''VPP Python language binding.''',
>zip_safe = True,
> )
> 
> Good, it lists pneum.  But the problem is, we shouldn't run this
> setup.py until after pneum is fully linked and on disk.  This happened
> too soon:
> 
> gcc -pthread -shared -Wl,-z,relro 
> build/temp.linux-x86_64-2.7/vpp_papi/pneum_wrap.o 
> -L/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64
>  -L. -lpneum -lpython2.7 -o build/lib.linux-x86_64-2.7/vpp_api.so
> /bin/ld: cannot find -lpneum
> 
> 
> Which means, the rule for vpp_api.so's dependencies, isn't listing the
> real pneum library properly.
> 
> I have no idea where that is supposed to take place yet.

I have also seen this error. What I suspect happens is that while pneum is 
already built and that the build dependency is correct, the library isn't 
installed under the install- directory yet.

I didn't manage to reproduce it right now, but would you mind trying this to 
see if it works:

diff --git a/src/vpp-api/python/Makefile.am b/src/vpp-api/python/Makefile.am
index 5407682..c60e4f4 100644
--- a/src/vpp-api/python/Makefile.am
+++ b/src/vpp-api/python/Makefile.am
@@ -39,7 +39,7 @@ libpneum_la_LDFLAGS = -module
 libpneum_la_CPPFLAGS =

 # TODO: Support both Python 2 and 3.
-install-exec-local:
+install-exec-local: install-libLTLIBRARIES
cd $(srcdir);   \
mkdir -p $(pythondir);  \
mkdir -p $(pyexecdir);  \


(In other news I am looking at using CFFI instead, and then the whole 
vpp_api.so would go away).

Cheers,
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] issues when enable proxy-arp

2017-03-08 Thread Neale Ranns (nranns)

Hi Pan,

I see nothing untoward there. Could you please send me instructions on how to 
re-create your setup. Then I can investigate why VPP restarts.

Thanks,
neale

From: "Pan, Xiao" 
Date: Wednesday, 8 March 2017 at 02:34
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] issues when enable proxy-arp

Hi, Neale
Thanks for help.
 In VPP16.06, there is no command like “sh adj” and “sh adj nbr N”, so I use 
VPP17.01 to get the two outputs.
And after my first ping from cont2(192.168.1.2) to cont1(192.168.1.1), no 
packet was received by cont1. And vpp will restart.

Below is the result:
# vppctl sh adj
[@0]
[@1] arp-ipv4: via 192.168.1.1 host-vpp1
[@2] arp-ipv4: via 192.168.1.2 host-vpp2
# vppctl sh adj nbr 1
[@1] arp-ipv4: via 192.168.1.1 host-vpp1
locks:4 node:[178]:ip4-arp next:[1]:host-vpp1-output
children:
  {path:11}
# vppctl sh adj nbr 2
[@2] arp-ipv4: via 192.168.1.2 host-vpp2
locks:4 node:[178]:ip4-arp next:[2]:host-vpp2-output
children:
  {path:12}

# vppctl sh ip fib 192.168.1.1
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
192.168.1.1/32 fib:0 index:11 locks:2
  src:CLI  refs:1
index:11 locks:2 proto:ipv4 flags:shared, uPRF-list:11 len:1 itfs:[4, ]
  index:11 pl-index:11 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   192.168.1.1 host-vpp1
  [@0]: arp-ipv4: via 192.168.1.1 host-vpp1

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [index:12 buckets:1 uRPF:11 to:[0:0]]
[0] [@3]: arp-ipv4: via 192.168.1.1 host-vpp1

# vppctl sh ip fib 192.168.1.2
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
192.168.1.2/32 fib:0 index:12 locks:2
  src:CLI  refs:1
index:12 locks:2 proto:ipv4 flags:shared, uPRF-list:12 len:1 itfs:[5, ]
  index:12 pl-index:12 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   192.168.1.2 host-vpp2
  [@0]: arp-ipv4: via 192.168.1.2 host-vpp2

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [index:13 buckets:1 uRPF:12 to:[0:0]]
[0] [@3]: arp-ipv4: via 192.168.1.2 host-vpp2

Thanks a lot!
Xiao Pan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, March 7, 2017 6:13 PM
To: Pan, Xiao ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] issues when enable proxy-arp

Hi Pan,

Could you please collect;
sh adj
sh adj nbr 5
sh ip fib 192.168.1.1

both before and after the first ping.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "Pan, Xiao" mailto:xiao@intel.com>>
Date: Tuesday, 7 March 2017 at 09:00
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] issues when enable proxy-arp

Hi, all
  I met an issue when enable proxy-arp in VPP.
  I have two containers, for instance, cont1 and cont2. Then set two VETH pairs 
for the two containers, 192.168.1.1 for cont1, 192.168.1.2 for cont2. The 
default route is below. The 169.254.1.1 is a dummy address.
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 169.254.1.1 0.0.0.0  UG0 0  
  0 eth0
169.254.1.1 0.0.0.0 255.255.255.255  UH0 00 
eth0

  Then in VPP, I attach to the two veth interface over the linux AF_PACKET 
interface.
vpp# show interface
  Name   Idx   State  Counter  Count
af_packet05 up
af_packet16 up

  Then config the proxy-arp and FIB:
vpp# set ip arp proxy 169.254.1.1 - 169.254.1.1
vpp# set int proxy-arp af_packet0 enable
vpp# set int proxy-arp af_packet1 enable
vpp# ip route add 192.168.1.1/32 via af_packet0
vpp# ip route add 192.168.1.2/32 via af_packet1

After that if I ping from cont1 to cont2, the cont2 will receive the packet and 
drop them all right away. I try to tcpdump the packet, get that:
[cid:image001.png@01D297E4.4A098040]
At the picture above, the left part is the packet that container1 sent to 
container2, and the right part is what container2 received.
You can see that the first 14 bytes are dropped by VPP, in which the first 12 
bytes is src and dst MAC, and the 13-14 bytes “0800” represents the type is 
VETH.

I met this problems in VPP16.06. And in VPP17.01, after my configuring and 
trying to ping, the vpp will restart itself and clean all my previous 
configuration☹.

I use “vppctl trace add dpdk-input 1” to detect the change of the packet in 
VPP. And ping from cont2(192.168.1.2) to cont1(192.168.1.1), get the result as 
below.

When the packet is sent out by the node “af_packet0-tx”, the length of the 
packet is 84 bytes.
I wonder why such operation will cut the first 14 bytes

00:54:30:521206: dpdk-input
  af_packet1 rx queue 0
  buffer 0x17af304: current data 0, length 98, free-list 0, totlen-nifb 0, 
trace 0x9
  PKT MBUF: port 1, nb_segs 1, pkt_len 98
buf_len 2176, data_len 98, ol_flags 0x0,
packet_type 0x0
  IP4: 3e:ca:93:00:28:bd -> 02:fe:79:66:eb:9a

Re: [vpp-dev] raspberrypi builds

2017-03-08 Thread Burt Silverman

Just for my curiosity, has it been done on RP 3 Model B?

On Tue, Mar 7, 2017 at 1:04 AM, Ilan Uriel  wrote:

> I am trying to build VPP on rp 2.
>
>
>
> I have tried both arm32 platform and vpp_lite but none would compile.
>
>
>
> It appears that there is a lot of work to be done before it can compile on
> RP.
>
>
>
> Am I missing something? Did someone actually compiled the code
> successfully on RP?
>
>
>
> If so, an explanation would be very much appreciated.
>
>
>
> Thanks
>
>
>
>
>
> ___
> 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] issues when enable proxy-arp

2017-03-08 Thread Pan, Xiao

Hi, Neale
Thanks for help.
Below is a script showing how I set up the network:

#!/bin/bash
# start two busybox containers, with none network
docker run -tid --name=con1 --network=none busybox
docker run -tid --name=con2 --network=none busybox

# remove the existing files
[ ! -d /var/run/netns/ ] && mkdir -p /var/run/netns
rm -Rf /var/run/netns/con1
rm -Rf /var/run/netns/con2

# expose the netns of a container to the host
pid=`docker inspect -f '{{.State.Pid}}' con1`
ln -s /proc/$pid/ns/net /var/run/netns/con1
# add a new veth pair, the host-side is vpp1, container-side is eth0
ip link add name eth0 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev eth0 up netns con1
# set the route in container
ip netns exec con1 ip addr add 192.168.1.1/32 dev eth0
ip netns exec con1 ip route replace 169.254.1.1 dev eth0
ip netns exec con1 ip route replace default via 169.254.1.1 dev eth0

# same to con1
pid=`docker inspect -f '{{.State.Pid}}' con2`
ln -s /proc/$pid/ns/net /var/run/netns/con2
ip link add name eth0 type veth peer name vpp2
ip link set dev vpp2 up
ip link set dev eth0 up netns con2
ip netns exec con2 ip addr add 192.168.1.2/32 dev eth0
ip netns exec con2 ip route replace 169.254.1.1 dev eth0
ip netns exec con2 ip route replace default via 169.254.1.1 dev eth0

vppctl create host-interface name vpp1
vppctl create host-interface name vpp2
vppctl set int state host-vpp1 up
vppctl set int state host-vpp2 up
vppctl set ip arp proxy 169.254.1.1 - 169.254.1.1
vppctl set int proxy-arp host-vpp1 enable
vppctl set int proxy-arp host-vpp2 enable
vppctl ip route add 192.168.1.1/32 via host-vpp1
vppctl ip route add 192.168.1.2/32 via host-vpp2


There is a little difference between different editions in the last part. In 
VPP16.06, I created af_packet interfaces via the (/etc/vpp/startup.conf). But 
in VPP17.01, I used “sreate host-interface” instead according to 
https://wiki.fd.io/index.php?title=VPP/Configure_VPP_As_A_Router_Between_Namespaces&oldid=4046

Then if I try
docker exec con1 ping -c5 192.168.1.2
VPP will restart and clean all my previous configuration.

Thanks a lot
Xiao Pan
From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Wednesday, March 8, 2017 4:17 PM
To: Pan, Xiao ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] issues when enable proxy-arp

Hi Pan,

I see nothing untoward there. Could you please send me instructions on how to 
re-create your setup. Then I can investigate why VPP restarts.

Thanks,
neale

From: "Pan, Xiao" mailto:xiao@intel.com>>
Date: Wednesday, 8 March 2017 at 02:34
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] issues when enable proxy-arp

Hi, Neale
Thanks for help.
 In VPP16.06, there is no command like “sh adj” and “sh adj nbr N”, so I use 
VPP17.01 to get the two outputs.
And after my first ping from cont2(192.168.1.2) to cont1(192.168.1.1), no 
packet was received by cont1. And vpp will restart.

Below is the result:
# vppctl sh adj
[@0]
[@1] arp-ipv4: via 192.168.1.1 host-vpp1
[@2] arp-ipv4: via 192.168.1.2 host-vpp2
# vppctl sh adj nbr 1
[@1] arp-ipv4: via 192.168.1.1 host-vpp1
locks:4 node:[178]:ip4-arp next:[1]:host-vpp1-output
children:
  {path:11}
# vppctl sh adj nbr 2
[@2] arp-ipv4: via 192.168.1.2 host-vpp2
locks:4 node:[178]:ip4-arp next:[2]:host-vpp2-output
children:
  {path:12}

# vppctl sh ip fib 192.168.1.1
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
192.168.1.1/32 fib:0 index:11 locks:2
  src:CLI  refs:1
index:11 locks:2 proto:ipv4 flags:shared, uPRF-list:11 len:1 itfs:[4, ]
  index:11 pl-index:11 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   192.168.1.1 host-vpp1
  [@0]: arp-ipv4: via 192.168.1.1 host-vpp1

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [index:12 buckets:1 uRPF:11 to:[0:0]]
[0] [@3]: arp-ipv4: via 192.168.1.1 host-vpp1

# vppctl sh ip fib 192.168.1.2
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
192.168.1.2/32 fib:0 index:12 locks:2
  src:CLI  refs:1
index:12 locks:2 proto:ipv4 flags:shared, uPRF-list:12 len:1 itfs:[5, ]
  index:12 pl-index:12 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   192.168.1.2 host-vpp2
  [@0]: arp-ipv4: via 192.168.1.2 host-vpp2

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [index:13 buckets:1 uRPF:12 to:[0:0]]
[0] [@3]: arp-ipv4: via 192.168.1.2 host-vpp2


Thanks a lot!
Xiao Pan


From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, March 7, 2017 6:13 PM
To: Pan, Xiao mailto:xiao@intel.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] issues when enable proxy-arp


Hi Pan,

Could you please collect;
sh adj
sh adj nbr 5
sh ip fib 192.168.1.1

both before and after the first ping.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "Pan, Xiao" mailto:xiao@intel.com>>
Date: Tuesday, 7 March 2017

Re: [vpp-dev] raspberrypi builds

2017-03-08 Thread Ilan Uriel

It was done on rp 2 model B and rp 3.
Both failed

From: Burt Silverman [mailto:bur...@gmail.com]
Sent: Wednesday, March 08, 2017 11:02 AM
To: Ilan Uriel
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] raspberrypi builds

Just for my curiosity, has it been done on RP 3 Model B?

On Tue, Mar 7, 2017 at 1:04 AM, Ilan Uriel 
mailto:il...@checkpoint.com>> wrote:
I am trying to build VPP on rp 2.

I have tried both arm32 platform and vpp_lite but none would compile.

It appears that there is a lot of work to be done before it can compile on RP.

Am I missing something? Did someone actually compiled the code successfully on 
RP?

If so, an explanation would be very much appreciated.

Thanks

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

Email secured by Check Point.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP on raspberry pi & 32 bit compilation

2017-03-08 Thread Ilan Uriel

Hi Christophe,

Have you been able to compile a working VPP on RP 2 or 3 at the end?

The existing stable releases seems to be far from providing either a code that 
can be compiled on any RP, using the PLATOFORM=arm32.

Any access available to the patches mentioned in the mail that can be used to 
compile VPP on/for RP?

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

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

2017-03-08 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)

Hi all,

I did some test in virl testbed. I sent following 3 frames to VPP interface 
from scapy:
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', 
dst='fa:16:3e:d0:4a:66')/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x8100)/Dot1Q(vlan=10)/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x)/IP())


In vpp_api_test I ran:
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up

exec show trace, it shows no Dot1Q frame
--- Start of thread 0 vpp_main ---
Packet 1

00:00:24:982426: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 14, length 20, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982450: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982460: ip4-lookup
  fib 0 dpo-idx 0 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982464: ip4-drop
IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
  tos 0x00, ttl 64, length 20, checksum 0x7ce7
  fragment id 0x0001
00:00:24:982467: error-drop
  ip4-input: ip4 adjacency drop

Packet 2

00:00:25:003176: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ddc: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33600
packet_type 0x0
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003179: ethernet-input
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003183: error-punt
  dpdk-input: no error


When I added the interface to a bridge domain there are 3 captured packets
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up
sw_interface_set_l2_bridge sw_if_index 1 bd_id 1 shg 0 enable
vat# exec show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:28:944099: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:28:944119: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:28:944127: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:00:28:944129: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944134: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944137: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944138: error-drop
  l2-flood: L2 replication complete

Packet 2

00:00:28:953150: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ddc: current data 0, length 38, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x0, data_off 128, phys_addr 0x4fd33600
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66 802.1q vlan 10
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:28:953153: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66 802.1q vlan 10
00:00:28:953155: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:00:28:953156: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:953156: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:953156: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:953157: error-drop
  l2-flood: L2 replication complete

Packet 3

00:00:28:962639: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4db5: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd32c40
packet_type 0x0
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:28:962641: ethernet-input
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:28:962643: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:

Re: [vpp-dev] R Signal events between graph nodes within different threads

2017-03-08 Thread Dave Barach (dbarach)

Guys,

Oh, you want the main thread to process packets? Why didn’t you simply ask how 
to do that in the first place?

At worst, a few lines’ worth of code - to enable e.g. dpdk-input in thread-0 - 
might be required. Copying Damjan.

Thanks… Dave

From: wang.hu...@zte.com.cn [mailto:wang.hu...@zte.com.cn]
Sent: Wednesday, March 8, 2017 2:50 AM
To: hongjun...@intel.com
Cc: alaga...@gmail.com; Dave Barach (dbarach) ; 
zhao.zhig...@zte.com.cn; gu.ji...@zte.com.cn; pan.feng...@zte.com.cn; 
vpp-dev@lists.fd.io
Subject: 答复: RE: R[vpp-dev] Signal events between graph nodes within different 
threads


Yes, I realize that, it could be work. Thanks to hongjun.

But vl_api_rpc_call_main_thread will degrade packet handling performance in 
worker thread, I don't know if there is a common and high performance way to do 
this?

And also  I guess vlib_process_signal_event can only be used in main thread? 
just my opinion, since I have not gone deep into the signal event code.





王辉 wanghui



IT开发工程师 IT Development Engineer
虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D 
Institute/Wireless Product Operation Division
原始邮件
发件人： ＜hongjun...@intel.com＞;
收件人：王辉10067165; ＜alaga...@gmail.com＞;
抄送人： ＜dbar...@cisco.com＞;赵志刚10017628;顾剑10036178;潘凤艳00024606; 
＜vpp-dev@lists.fd.io＞;
日 期 ：2017年03月08日 15:18
主 题 ：RE: R[vpp-dev]  Signal events between graph nodes within different threads


Hi Hui,

I think the SNAT example maybe meet what you want:

snat_in2out_node_fn_inline: (in worker thread)
 slow_path
snat_ipfix_logging_nat44_ses_create
vl_api_rpc_call_main_thread

Regards,
Hongjun

From: wang.hu...@zte.com.cn 
[mailto:wang.hu...@zte.com.cn]
Sent: Wednesday, March 8, 2017 2:58 PM
To: alaga...@gmail.com
Cc: dbar...@cisco.com; Ni, Hongjun 
＜hongjun...@intel.com＞; 
zhao.zhig...@zte.com.cn; 
gu.ji...@zte.com.cn; 
pan.feng...@zte.com.cn; 
vpp-dev@lists.fd.io
Subject: 答复: Re: [vpp-dev] 答复: Re: Signal events between graph nodes within 
different threads


Maybe if you could expand on what it is you are trying to achieve?

//when starting worker thread ,  the main thread can't receive packet from IO, 
so we want to transfer some packet to main thread to continue processing.



Is it specifically to do with DHCP (and proxy) or is that just the code you 
found that looks like the kind of functionality you believe you need for your 
use-case?

// that just looks like our use-case. vlib_process_signal_event called in 
worker thread, and signal an event to the dhcp proccess node in main thread.

can  vlib_process_signal_event  do this?









王辉 wanghui



IT开发工程师 IT Development Engineer
虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D  
Institute/Wireless Product Operation Division
原始邮件
发件人： ＜alaga...@gmail.com＞;
收件人：王辉10067165; ＜dbar...@cisco.com＞; ＜hongjun...@intel.com＞;
抄送人：赵志刚10017628;顾剑10036178;潘凤艳00024606; ＜vpp-dev@lists.fd.io＞;
日 期 ：2017年03月08日  13:04
主 题 ：Re: [vpp-dev] 答复: Re: Signal events between graph nodes within different 
threads



On Wed, Mar 8, 2017 at 2:29 PM 
＜wang.hu...@zte.com.cn＞ wrote:

hi Dave and hongjun:



We also got  confused with below code. Dos it works correctly?

Maybe the dhcp_proxy_to_client_input  fuction runs in the worker thread,  and 
it will call vlib_process_signal_event function to trigger dhcp-proccess node 
in the main thread.

If it works, maybe the question of mail title could be solved. But We can't 
find any other use like this until now.


Maybe if you could expand on what it is you are trying to achieve?

Is it specifically to do with DHCP (and proxy) or is that just the code you 
found that looks like the kind of functionality you believe you need for your 
use-case?





dhcp_proxy_to_client_input

dhcp_client_for_us

vlib_process_signal_event (vm, dhcp_client_process_node.index,

 EVENT_DHCP_CLIENT_WAKEUP, c - dcm-＞clients);











王辉 wanghui



IT开发工程师 IT Development Engineer
虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D  
Institute/Wireless Product Operation Division




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

[vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

2017-03-08 Thread Leonardo Linguaglossa

Hello,

I am currently working on VPP version 17.04 and I wanted to perform some
measurements w.r.t. the VLIB_FRAME_SIZE, defined in
VPP_ROOT/src/vlib/node.h.

1.
The issue is that when I define a smaller vector size

> #define VLIB_FRAME_SIZE 128
>

I get an error in the vlib/main.c assertion:

> /*in vlib/main.c line 483*/
> ASSERT (n_vectors_left <= VLIB_FRAME_SIZE);
>

2.
Otherwise, if I define a bigger value

> #define VLIB_FRAME_SIZE 512
>

Then I get a different error, this time in vlib/physmem.c

> /*in vlib/physmem.h line 96*/
> ASSERT (offset < pm->virtual.size);
>

I would like to ask whether VPP is currently able to manage vector sizes
different than 256. If not, how difficult would it be to adapt a different
vector size to my vpp version?

Thank you in advance,
-- 
Leonardo
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

2017-03-08 Thread Dave Barach (dbarach)

Please make absolutely sure that (a) you’ve compiled the tree from scratch, and 
(b) that you’re not tripping over previously-installed shared libraries built 
with a different VLIB_FRAME_SIZE.

Why are you interested in changing VLIB_FRAME_SIZE in the first place?

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Leonardo Linguaglossa
Sent: Wednesday, March 8, 2017 9:11 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Hello,
I am currently working on VPP version 17.04 and I wanted to perform some 
measurements w.r.t. the VLIB_FRAME_SIZE, defined in VPP_ROOT/src/vlib/node.h.

1.
The issue is that when I define a smaller vector size
#define VLIB_FRAME_SIZE 128

I get an error in the vlib/main.c assertion:
/*in vlib/main.c line 483*/
ASSERT (n_vectors_left <= VLIB_FRAME_SIZE);

2.
Otherwise, if I define a bigger value
#define VLIB_FRAME_SIZE 512

Then I get a different error, this time in vlib/physmem.c
/*in vlib/physmem.h line 96*/
ASSERT (offset < pm->virtual.size);

I would like to ask whether VPP is currently able to manage vector sizes 
different than 256. If not, how difficult would it be to adapt a different 
vector size to my vpp version?
Thank you in advance,
--
Leonardo
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

2017-03-08 Thread Thomas F Herbert


Maxime,

The

OK. Thanks. I am forwarding this to Pierre as he has been working on 
vhost-user.


I thought we were now using dpdk's vhost-user driver as of 17.01.

It is interesting how we haven't seen this in our csit testing and we 
are testing multi-queue. Also will this manifest only on certain 
revisions of Qemu/KVM?


--TFH

 Forwarded Message 
Subject: 	[Bug 1422534] vdev->vq[i] .used_idx does not consider the 
right value for vhostuser

Date:   Wed, 08 Mar 2017 08:56:49 +
From:   bugzi...@redhat.com
To: therb...@redhat.com



https://bugzilla.redhat.com/show_bug.cgi?id=1422534



--- Comment #27 from Maxime Coquelin  ---
Tom,

I had a look at mainline VPP:
$ build-root/scripts/version
17.04-rc0~382-ga0b34a7

Looking at 16.06 release, it seems to be a regression, as the vring struct is
not reset before getting last_avail_idx, only the enable bit is cleared:

case VHOST_USER_GET_VRING_BASE:
  DBG_SOCK("if %d msg VHOST_USER_GET_VRING_BASE idx %d num %d",
vui->hw_if_index, msg.state.index, msg.state.num);

  /* Spec says: Client must [...] stop ring upon receiving
VHOST_USER_GET_VRING_BASE. */
  vui->vrings[msg.state.index].enabled = 0;

  msg.state.num = vui->vrings[msg.state.index].last_avail_idx;
  msg.flags |= 4;
  msg.size = sizeof(msg.state);
  break;

The regression seems to have been introduced by below commit, which landed into
v17.01 release:

$  git blame src/vnet/devices/virtio/vhost-user.c -L 1031
e21c5286 vnet/vnet/devices/virtio/vhost-user.c (Pierre Pfister 2016-09-21
08:04:59 +0100 1031)   vhost_user_vring_close (vui, msg.state.index);

$ git show e21c5286
commit e21c52861d7c503bef7fc464f23bbc7891e150d7
Author: Pierre Pfister 
Date:   Wed Sep 21 08:04:59 2016 +0100

vhost-user: multiqueue support

This patch adds multi-queue support to non-dpdk's vhost-user
driver.
Waiting for a unified way to manage threads, this patch
defines a way to assign threads to interfaces that is
specific to vhost.

Change-Id: I86298788b1a4e886c5431f187dc17175d12c7a8b
Signed-off-by: Pierre Pfister 

$ git tag --contains e21c5286
v17.01
v17.01-rc1
v17.01-rc2
v17.01.1
v17.04-rc0
We should invite Pierre Pfister from Cisco in the discussion,
as he might have some ideas on the fix to do.

I guess that reverting to just clearing the enabled bit is not the right fix.
Maybe the vring struct shouldn't be re-initialized in the close function,
but should be called directly when needed.

I'm attaching a debug patch to confirm the root cause if someone want to have a
try.
It is not intended to be the fix for this issue, and has not neither been
compiled nor tested.

Regards,
Maxime

--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=Y79DLPsrVV&a=cc_unsubscribe

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

Re: [vpp-dev] fd.io CSIT vhost-user test scenario implementation priorities

2017-03-08 Thread Maciek Konstantynowicz (mkonstan)

Hi,

Suggest we discuss it on the next CSIT project call (today?) if we get all the 
interested or arrange a separate TWS call.
General note:
Within CSIT we’re focusing on verifying FD.io VPP capabilities 
and properties incl. integration with operating environment.
More complete solution testing including interop with VNFs is out of scope, and 
per Alec’s note we should consider driving this into project where this belongs 
e.g. OPNFV.

Few more comments from my side inline [mk] ..

On 28 Feb 2017, at 21:04, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:


Comments inline…


From: "Liew, Irene" mailto:irene.l...@intel.com>>
Date: Tuesday, February 28, 2017 at 10:25 AM
To: Thomas F Herbert mailto:therb...@redhat.com>>, 
"csit-...@lists.fd.io" 
mailto:csit-...@lists.fd.io>>, "Maciek Konstantynowicz 
(mkonstan)" mailto:mkons...@cisco.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>, "Pierre Pfister 
(ppfister)" mailto:ppfis...@cisco.com>>, "Alec Hothan 
(ahothan)" mailto:ahot...@cisco.com>>, Karl Rister 
mailto:kris...@redhat.com>>, Douglas Shakshober 
mailto:dsh...@redhat.com>>, Andrew Theurer 
mailto:atheu...@redhat.com>>, "Liew, Irene" 
mailto:irene.l...@intel.com>>
Subject: RE: fd.io CSIT vhost-user test scenario implementation 
priorities

Here are my thoughts and comments on the topologies/test and workloads for CSIT 
vhost-user test scenarios. Pls refer to my comments inline below.

-Original Message-
From: Thomas F Herbert [mailto:therb...@redhat.com]
Sent: Monday, February 27, 2017 10:04 AM
To: csit-...@lists.fd.io; Maciek Konstantynowicz 
(mkonstan) mailto:mkons...@cisco.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; Liew, Irene 
mailto:irene.l...@intel.com>>; Pierre Pfister (ppfister) 
mailto:ppfis...@cisco.com>>; Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>>; Karl Rister 
mailto:kris...@redhat.com>>; Douglas Shakshober 
mailto:dsh...@redhat.com>>; Andrew Theurer 
mailto:atheu...@redhat.com>>
Subject: fd.io CSIT vhost-user test scenario implementation 
priorities

Please weigh in:

We are starting to plan fd.io CSIT Vhost-user test scenario 
priorities for implementation in 17.04 and  in 17.07 CSIT releases.

Vhost-user performance is critical for VNF acceptance in potential use cases 
for VPP/fd.io adaption.

We had previous email thread here:
https://lists.fd.io/pipermail/csit-dev/2016-November/001192.html along with a 
TWS https://wiki.fd.io/view/TWS meetings on 12/02/16 and 12/07/16
  summarized in this wiki:
https://wiki.fd.io/view/CSIT/vhostuser_test_scenarios

Topologies and tests

Current in 17.01:

10ge2p1x520-dot1q-l2bdbasemaclrn-eth-2vhost-1vm
10ge2p1x520-dot1q-l2xcbase-eth-2vhost-1vm
10ge2p1x520-ethip4-ip4base-eth-2vhost-1vm
10ge2p1x520-ethip4vxlan-l2bdbasemaclrn-eth-2vhost-1vm
10ge2p1x520-eth-l2bdbasemaclrn-eth-2vhost-1vm
10ge2p1x520-eth-l2xcbase-eth-2vhost-1vm
10ge2p1x710-eth-l2bdbasemaclrn-eth-2vhost-1vm
40ge2p1xl710-eth-l2bdbasemaclrn-eth-2vhost-1vm

single and multi-queue

[mk] Agree, multi-queue for multi-thread setups.


testing of pmd baseline

[mk] That’s already in csit for x520 NIC (reaching NIC pps limit), adding xl710 
is having hiccups.


Proposed in links above
 1p1nic-dot1q-l2bdbase-eth-2vhost-1vm
 1p1nic-ethip4vxlan-l2bdbase-eth-2vhost-1vm
 1p1nic-dot1q-l2bdbase-eth-4vhost-2vm-chain
 1p1nic-ethip4vxlan-l2bdbase-eth-4vhost-2vm-chain
 1p1nic-dot1q-l2bdbase-eth-2vhost-1vm-chain-2nodes
 1p1nic-ethip4vxlan-l2bdbase-eth-2vhost-1vm-2nodes


[mk] In the current LF setup, unless we use a two-node topology, we can’t do 
1p1nic perf tests.

[Irene] For the baseline testing on vhost-user, I would recommend to run core 
scaling from 1 core - max cores for 1 VM Phy-VM-Phy and 2 VMs PVVP. I know the 
current VPP v17.01  did not have the support to manually assign the vhost-user 
ports RXQ to specific cores to ensure load balancing across the cores. And from 
our experience in the lab, when I ran 3-core of work threads in 4vhost-2vm PVVP 
configuration, I observed the ports were unevenly distributed across 3 worker 
threads and VPP vNet suffered in performance scalability. If the manual RXQ 
assignment for vhost-user port feature will be made available in the next 17.04 
or 17.07 release, I strongly propose to include the core scaling of worker 
threads in order to evaluate the vhost-user RXQ core assignment feature. For 
example, we can pick 1 test case of 2 vhost-1vm  and run with configuration of 
1-core, 2-core and 4-core of worker threads. We then pick 1 test case of 
4vhost-2vm-chain and run with configuration of 1-core, 2-core, 3-core, 4-core 
and 6-core of worker threads.

To limit the number of test I suggest we use 1,2,4 physical cores. I don’t 
think there will be many deployments with 6 or more physical cores for the 
vswitch (but I’m only talking about openstack-NFV deployments).
One interesting va

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

2017-03-08 Thread Leonardo Linguaglossa

Thank you for your reply,

I actually re-built everything ( make wipe-release && make build-release ).
I don't know if this also affects the shared libraries.

The idea is to perform some experiments as a function of the frame size,
and in order to do this, I need to modify the VLIB_FRAME_SIZE definition.


2017-03-08 15:25 GMT+01:00 Dave Barach (dbarach) :

> Please make absolutely sure that (a) you’ve compiled the tree from
> scratch, and (b) that you’re not tripping over previously-installed shared
> libraries built with a different VLIB_FRAME_SIZE.
>
>
>
> Why are you interested in changing VLIB_FRAME_SIZE in the first place?
>
>
>
> Thanks… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Leonardo Linguaglossa
> *Sent:* Wednesday, March 8, 2017 9:11 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]
>
>
>
> Hello,
>
> I am currently working on VPP version 17.04 and I wanted to perform some
> measurements w.r.t. the VLIB_FRAME_SIZE, defined in
> VPP_ROOT/src/vlib/node.h.
>
> 1.
>
> The issue is that when I define a smaller vector size
>
> #define VLIB_FRAME_SIZE 128
>
>
>
> I get an error in the vlib/main.c assertion:
>
> /*in vlib/main.c line 483*/
> ASSERT (n_vectors_left <= VLIB_FRAME_SIZE);
>
>
> 2.
>
> Otherwise, if I define a bigger value
>
> #define VLIB_FRAME_SIZE 512
>
>
>
> Then I get a different error, this time in vlib/physmem.c
>
> /*in vlib/physmem.h line 96*/
>
> ASSERT (offset < pm->virtual.size);
>
>
>
> I would like to ask whether VPP is currently able to manage vector sizes
> different than 256. If not, how difficult would it be to adapt a different
> vector size to my vpp version?
>
> Thank you in advance,
> --
>
> Leonardo
>



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

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

2017-03-08 Thread Maxime Coquelin


Tom,

On 03/08/2017 03:59 PM, Thomas F Herbert wrote:

Maxime,

The

OK. Thanks. I am forwarding this to Pierre as he has been working on
vhost-user.

I thought we were now using dpdk's vhost-user driver as of 17.01.

No it isn't.
I would be interested in the reasons not doing the move, and propose my
help if this is in VPP project plans.



It is interesting how we haven't seen this in our csit testing and we
are testing multi-queue. Also will this manifest only on certain
revisions of Qemu/KVM?


My understanding is:
Before VPP 17.01, migration was fine whatever the QEMU version.
The bug has been introduced in VPP 17.01 in commit e21c5286. From this
commit, VPP will always reply 0 to GET_VRING_BASE whatever the real
last_avail_idx value.

But, depending on QEMU version, the problem will or won't be detected.
If QEMU doesn't contain commit "virtio: recalculate vq->inuse after
migration", then the bug will be silent and last_avail_idx will be
wrongly restored in destination backend.
If QEMU contains this patch, problem is detected and migration fails.

Do you know which QEMU version you are using in your CSIT testing?
I can check whether it contains this patch.

Regards,
Maxime


--TFH

 Forwarded Message 
Subject:[Bug 1422534] vdev->vq[i] .used_idx does not consider the
right value for vhostuser
Date:   Wed, 08 Mar 2017 08:56:49 +
From:   bugzi...@redhat.com
To: therb...@redhat.com



https://bugzilla.redhat.com/show_bug.cgi?id=1422534



--- Comment #27 from Maxime Coquelin  ---
Tom,

I had a look at mainline VPP:
$ build-root/scripts/version
17.04-rc0~382-ga0b34a7

Looking at 16.06 release, it seems to be a regression, as the vring struct is
not reset before getting last_avail_idx, only the enable bit is cleared:

case VHOST_USER_GET_VRING_BASE:
  DBG_SOCK("if %d msg VHOST_USER_GET_VRING_BASE idx %d num %d",
vui->hw_if_index, msg.state.index, msg.state.num);

  /* Spec says: Client must [...] stop ring upon receiving
VHOST_USER_GET_VRING_BASE. */
  vui->vrings[msg.state.index].enabled = 0;

  msg.state.num = vui->vrings[msg.state.index].last_avail_idx;
  msg.flags |= 4;
  msg.size = sizeof(msg.state);
  break;

The regression seems to have been introduced by below commit, which landed into
v17.01 release:

$  git blame src/vnet/devices/virtio/vhost-user.c -L 1031
e21c5286 vnet/vnet/devices/virtio/vhost-user.c (Pierre Pfister 2016-09-21
08:04:59 +0100 1031)   vhost_user_vring_close (vui, msg.state.index);

$ git show e21c5286
commit e21c52861d7c503bef7fc464f23bbc7891e150d7
Author: Pierre Pfister 
Date:   Wed Sep 21 08:04:59 2016 +0100

vhost-user: multiqueue support

This patch adds multi-queue support to non-dpdk's vhost-user
driver.
Waiting for a unified way to manage threads, this patch
defines a way to assign threads to interfaces that is
specific to vhost.

Change-Id: I86298788b1a4e886c5431f187dc17175d12c7a8b
Signed-off-by: Pierre Pfister 

$ git tag --contains e21c5286
v17.01
v17.01-rc1
v17.01-rc2
v17.01.1
v17.04-rc0
We should invite Pierre Pfister from Cisco in the discussion,
as he might have some ideas on the fix to do.

I guess that reverting to just clearing the enabled bit is not the right fix.
Maybe the vring struct shouldn't be re-initialized in the close function,
but should be called directly when needed.

I'm attaching a debug patch to confirm the root cause if someone want to have a
try.
It is not intended to be the fix for this issue, and has not neither been
compiled nor tested.

Regards,
Maxime

--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=Y79DLPsrVV&a=cc_unsubscribe


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

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

2017-03-08 Thread Steven Luong (sluong)

Maxime,

Last I heard csit uses qemu 2.5. Could you please check if the
aforementioned patch exists in that qemu version?

Steven

On 3/8/17, 7:36 AM, "vpp-dev-boun...@lists.fd.io on behalf of Maxime
Coquelin"  wrote:

>Tom,
>
>On 03/08/2017 03:59 PM, Thomas F Herbert wrote:
>> Maxime,
>>
>> The
>>
>> OK. Thanks. I am forwarding this to Pierre as he has been working on
>> vhost-user.
>>
>> I thought we were now using dpdk's vhost-user driver as of 17.01.
>No it isn't.
>I would be interested in the reasons not doing the move, and propose my
>help if this is in VPP project plans.
>
>>
>> It is interesting how we haven't seen this in our csit testing and we
>> are testing multi-queue. Also will this manifest only on certain
>> revisions of Qemu/KVM?
>
>My understanding is:
>Before VPP 17.01, migration was fine whatever the QEMU version.
>The bug has been introduced in VPP 17.01 in commit e21c5286. From this
>commit, VPP will always reply 0 to GET_VRING_BASE whatever the real
>last_avail_idx value.
>
>But, depending on QEMU version, the problem will or won't be detected.
>If QEMU doesn't contain commit "virtio: recalculate vq->inuse after
>migration", then the bug will be silent and last_avail_idx will be
>wrongly restored in destination backend.
>If QEMU contains this patch, problem is detected and migration fails.
>
>Do you know which QEMU version you are using in your CSIT testing?
>I can check whether it contains this patch.
>
>Regards,
>Maxime
>>
>> --TFH
>>
>>  Forwarded Message 
>> Subject: [Bug 1422534] vdev->vq[i] .used_idx does not consider the
>> right value for vhostuser
>> Date:Wed, 08 Mar 2017 08:56:49 +
>> From:bugzi...@redhat.com
>> To:  therb...@redhat.com
>>
>>
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1422534
>>
>>
>>
>> --- Comment #27 from Maxime Coquelin  ---
>> Tom,
>>
>> I had a look at mainline VPP:
>> $ build-root/scripts/version
>> 17.04-rc0~382-ga0b34a7
>>
>> Looking at 16.06 release, it seems to be a regression, as the vring
>>struct is
>> not reset before getting last_avail_idx, only the enable bit is cleared:
>>
>> case VHOST_USER_GET_VRING_BASE:
>>   DBG_SOCK("if %d msg VHOST_USER_GET_VRING_BASE idx %d num %d",
>> vui->hw_if_index, msg.state.index, msg.state.num);
>>
>>   /* Spec says: Client must [...] stop ring upon receiving
>> VHOST_USER_GET_VRING_BASE. */
>>   vui->vrings[msg.state.index].enabled = 0;
>>
>>   msg.state.num = vui->vrings[msg.state.index].last_avail_idx;
>>   msg.flags |= 4;
>>   msg.size = sizeof(msg.state);
>>   break;
>>
>> The regression seems to have been introduced by below commit, which
>>landed into
>> v17.01 release:
>>
>> $  git blame src/vnet/devices/virtio/vhost-user.c -L 1031
>> e21c5286 vnet/vnet/devices/virtio/vhost-user.c (Pierre Pfister
>>2016-09-21
>> 08:04:59 +0100 1031)   vhost_user_vring_close (vui,
>>msg.state.index);
>>
>> $ git show e21c5286
>> commit e21c52861d7c503bef7fc464f23bbc7891e150d7
>> Author: Pierre Pfister 
>> Date:   Wed Sep 21 08:04:59 2016 +0100
>>
>> vhost-user: multiqueue support
>>
>> This patch adds multi-queue support to non-dpdk's vhost-user
>> driver.
>> Waiting for a unified way to manage threads, this patch
>> defines a way to assign threads to interfaces that is
>> specific to vhost.
>>
>> Change-Id: I86298788b1a4e886c5431f187dc17175d12c7a8b
>> Signed-off-by: Pierre Pfister 
>>
>> $ git tag --contains e21c5286
>> v17.01
>> v17.01-rc1
>> v17.01-rc2
>> v17.01.1
>> v17.04-rc0
>> We should invite Pierre Pfister from Cisco in the discussion,
>> as he might have some ideas on the fix to do.
>>
>> I guess that reverting to just clearing the enabled bit is not the
>>right fix.
>> Maybe the vring struct shouldn't be re-initialized in the close
>>function,
>> but should be called directly when needed.
>>
>> I'm attaching a debug patch to confirm the root cause if someone want
>>to have a
>> try.
>> It is not intended to be the fix for this issue, and has not neither
>>been
>> compiled nor tested.
>>
>> Regards,
>> Maxime
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>> Unsubscribe from this bug
>>https://bugzilla.redhat.com/token.cgi?t=Y79DLPsrVV&a=cc_unsubscribe
>>
>___
>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] dpdk input-node fixed sleep => low load average on my vpp home gateway

2017-03-08 Thread Dave Barach (dbarach)

FYI,

I just pushed a patch to change the units of the dpdk "poll-sleep" parameter 
from milliseconds to microseconds. Set as shown below, my vpp home gateway runs 
at a very low load-average:

dbarach@vppgate:~$ uptime
10:34:00 up 16 days, 23:41, 1 user, load average: 0.07, 0.25, 0.62

No issues keeping up with a ~ 100mbit downstream link, no obvious VoIP issues. 
Speedtest.net managed to push the vector size to 3, vs 1.7 when polling 
aggressively.

@@ -96,4 +102,7 @@ dpdk {
+
+## Sleep for 300 us between polls
+poll-sleep 300
}

Related patch to change the configuration parameter units: 
https://gerrit.fd.io/r/#/c/5674/

Thanks... Dave

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

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

2017-03-08 Thread Dave Barach (dbarach)

“I don't know if this also affects the shared libraries.”

$ ls -l /usr/lib/x86_64-linux-gnu/libvlib.so.0.0.0

to work out whether the installed shared libs are newer or older than your 
change to node.h...

Thanks… Dave

From: theleo...@gmail.com [mailto:theleo...@gmail.com] On Behalf Of Leonardo 
Linguaglossa
Sent: Wednesday, March 8, 2017 9:54 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Thank you for your reply,
I actually re-built everything ( make wipe-release && make build-release ). I 
don't know if this also affects the shared libraries.
The idea is to perform some experiments as a function of the frame size, and in 
order to do this, I need to modify the VLIB_FRAME_SIZE definition.

2017-03-08 15:25 GMT+01:00 Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>:
Please make absolutely sure that (a) you’ve compiled the tree from scratch, and 
(b) that you’re not tripping over previously-installed shared libraries built 
with a different VLIB_FRAME_SIZE.

Why are you interested in changing VLIB_FRAME_SIZE in the first place?

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Leonardo Linguaglossa
Sent: Wednesday, March 8, 2017 9:11 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Hello,
I am currently working on VPP version 17.04 and I wanted to perform some 
measurements w.r.t. the VLIB_FRAME_SIZE, defined in VPP_ROOT/src/vlib/node.h.

1.
The issue is that when I define a smaller vector size
#define VLIB_FRAME_SIZE 128

I get an error in the vlib/main.c assertion:
/*in vlib/main.c line 483*/
ASSERT (n_vectors_left <= VLIB_FRAME_SIZE);

2.
Otherwise, if I define a bigger value
#define VLIB_FRAME_SIZE 512

Then I get a different error, this time in vlib/physmem.c
/*in vlib/physmem.h line 96*/
ASSERT (offset < pm->virtual.size);

I would like to ask whether VPP is currently able to manage vector sizes 
different than 256. If not, how difficult would it be to adapt a different 
vector size to my vpp version?
Thank you in advance,
--
Leonardo



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

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

2017-03-08 Thread Maxime Coquelin


Steven,

On 03/08/2017 04:44 PM, Steven Luong (sluong) wrote:

Maxime,

Last I heard csit uses qemu 2.5. Could you please check if the
aforementioned patch exists in that qemu version?

In upstream QEMU, the patch landed into v2.7.0 tag, so if you are using
upstream version then the patch is not there.

Regards,
Maxime



Steven

On 3/8/17, 7:36 AM, "vpp-dev-boun...@lists.fd.io on behalf of Maxime
Coquelin"  wrote:


Tom,

On 03/08/2017 03:59 PM, Thomas F Herbert wrote:

Maxime,

The

OK. Thanks. I am forwarding this to Pierre as he has been working on
vhost-user.

I thought we were now using dpdk's vhost-user driver as of 17.01.

No it isn't.
I would be interested in the reasons not doing the move, and propose my
help if this is in VPP project plans.



It is interesting how we haven't seen this in our csit testing and we
are testing multi-queue. Also will this manifest only on certain
revisions of Qemu/KVM?


My understanding is:
Before VPP 17.01, migration was fine whatever the QEMU version.
The bug has been introduced in VPP 17.01 in commit e21c5286. From this
commit, VPP will always reply 0 to GET_VRING_BASE whatever the real
last_avail_idx value.

But, depending on QEMU version, the problem will or won't be detected.
If QEMU doesn't contain commit "virtio: recalculate vq->inuse after
migration", then the bug will be silent and last_avail_idx will be
wrongly restored in destination backend.
If QEMU contains this patch, problem is detected and migration fails.

Do you know which QEMU version you are using in your CSIT testing?
I can check whether it contains this patch.

Regards,
Maxime


--TFH

 Forwarded Message 
Subject:[Bug 1422534] vdev->vq[i] .used_idx does not consider the
right value for vhostuser
Date:   Wed, 08 Mar 2017 08:56:49 +
From:   bugzi...@redhat.com
To: therb...@redhat.com



https://bugzilla.redhat.com/show_bug.cgi?id=1422534



--- Comment #27 from Maxime Coquelin  ---
Tom,

I had a look at mainline VPP:
$ build-root/scripts/version
17.04-rc0~382-ga0b34a7

Looking at 16.06 release, it seems to be a regression, as the vring
struct is
not reset before getting last_avail_idx, only the enable bit is cleared:

case VHOST_USER_GET_VRING_BASE:
  DBG_SOCK("if %d msg VHOST_USER_GET_VRING_BASE idx %d num %d",
vui->hw_if_index, msg.state.index, msg.state.num);

  /* Spec says: Client must [...] stop ring upon receiving
VHOST_USER_GET_VRING_BASE. */
  vui->vrings[msg.state.index].enabled = 0;

  msg.state.num = vui->vrings[msg.state.index].last_avail_idx;
  msg.flags |= 4;
  msg.size = sizeof(msg.state);
  break;

The regression seems to have been introduced by below commit, which
landed into
v17.01 release:

$  git blame src/vnet/devices/virtio/vhost-user.c -L 1031
e21c5286 vnet/vnet/devices/virtio/vhost-user.c (Pierre Pfister
2016-09-21
08:04:59 +0100 1031)   vhost_user_vring_close (vui,
msg.state.index);

$ git show e21c5286
commit e21c52861d7c503bef7fc464f23bbc7891e150d7
Author: Pierre Pfister 
Date:   Wed Sep 21 08:04:59 2016 +0100

vhost-user: multiqueue support

This patch adds multi-queue support to non-dpdk's vhost-user
driver.
Waiting for a unified way to manage threads, this patch
defines a way to assign threads to interfaces that is
specific to vhost.

Change-Id: I86298788b1a4e886c5431f187dc17175d12c7a8b
Signed-off-by: Pierre Pfister 

$ git tag --contains e21c5286
v17.01
v17.01-rc1
v17.01-rc2
v17.01.1
v17.04-rc0
We should invite Pierre Pfister from Cisco in the discussion,
as he might have some ideas on the fix to do.

I guess that reverting to just clearing the enabled bit is not the
right fix.
Maybe the vring struct shouldn't be re-initialized in the close
function,
but should be called directly when needed.

I'm attaching a debug patch to confirm the root cause if someone want
to have a
try.
It is not intended to be the fix for this issue, and has not neither
been
compiled nor tested.

Regards,
Maxime

--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=Y79DLPsrVV&a=cc_unsubscribe


___
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] [csit-dev] installation issue of release rpm packages from Nexus on centos7 system

2017-03-08 Thread Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)

Hello Tom,

Based on our discussion during today's CSIT call I started the csit semiweekly 
job - unfortunately still the same conflict reported during installation of VPP 
RPM packages:

jenkins-in@t4-virl2:~$ start-testcase -vv -c double-ring-nested.centos7 -r 
csit-centos-7.3-1611_2017-02-23_1.4 
/tmp/vpp-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
/tmp/vpp-debuginfo-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
/tmp/vpp-devel-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
/tmp/vpp-dpdk-devel-17.02-vpp1.x86_64.rpm 
/tmp/vpp-lib-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
/tmp/vpp-plugins-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm
DEBUG: Running with topology double-ring-nested.centos7
DEBUG: Checking if file /tmp/vpp-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm exists
DEBUG: Checking if file 
/tmp/vpp-debuginfo-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm exists
DEBUG: Checking if file /tmp/vpp-devel-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
exists
DEBUG: Checking if file /tmp/vpp-dpdk-devel-17.02-vpp1.x86_64.rpm exists
DEBUG: Checking if file /tmp/vpp-lib-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm 
exists
DEBUG: Checking if file 
/tmp/vpp-plugins-17.04-rc0~387_g141ecc5~b2011.x86_64.rpm exists
DEBUG: Starting VIRL topology
DEBUG: - Response Code 200
DEBUG: Waiting for simulation to become active
DEBUG: - Attempt 1 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 2 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 3 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 4 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 5 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 6 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 7 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 8 out of 24, total 3 hosts, 0 active
DEBUG: - Attempt 9 out of 24, total 3 hosts, 3 active
DEBUG: Nodes: tg1, sut1, sut2
DEBUG: Node tg1 is of type tg and has management IP 10.30.51.140
DEBUG: Node sut1 is of type sut and has management IP 10.30.51.142
DEBUG: Node sut2 is of type sut and has management IP 10.30.51.141
DEBUG: Waiting for hosts to become reachable using SSH
DEBUG: - Attempt 1 out of 24, waiting for 0 hosts
DEBUG: Uprading VPP
DEBUG: Upgrading VPP on node 10.30.51.142
DEBUG: Installing RPM packages
DEBUG: Command output was:
Preparing...  

DEBUG: Command stderr was:
   file /usr/include/dpdk conflicts between attempted installs of 
vpp-dpdk-devel-17.02-vpp1.x86_64 and 
vpp-devel-17.04-rc0~387_g141ecc5~b2011.x86_64

DEBUG: Upgrading VPP on node 10.30.51.141
DEBUG: Installing RPM packages
DEBUG: Command output was:
Preparing...  

DEBUG: Command stderr was:
   file /usr/include/dpdk conflicts between attempted installs of 
vpp-dpdk-devel-17.02-vpp1.x86_64 and 
vpp-devel-17.04-rc0~387_g141ecc5~b2011.x86_64

SESSION ID: session-4Y8gHl
session-4Y8gHl

Regards,
Jan

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Thomas F Herbert
Sent: Tuesday, March 07, 2017 15:56
To: csit-...@lists.fd.io; vpp-dev 
Subject: Re: [vpp-dev] [csit-dev] installation issue of release rpm packages 
from Nexus on centos7 system




On 03/07/2017 04:53 AM, Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at 
Cisco) wrote:
Hello vpp developers,

We are facing following issue during installation of release vpp rpm packages 
downloaded from Nexus on VIRL:

DEBUG: Running with topology double-ring-nested.centos7
DEBUG: Checking if file /tmp/vpp-17.04-rc0~359_g077d6ae~b1983.x86_64.rpm exists
DEBUG: Checking if file 
/tmp/vpp-debuginfo-17.04-rc0~359_g077d6ae~b1983.x86_64.rpm exists
DEBUG: Checking if file /tmp/vpp-devel-17.04-rc0~359_g077d6ae~b1983.x86_64.rpm 
exists
DEBUG: Checking if file /tmp/vpp-dpdk-devel-17.02-vpp1.x86_64.rpm exists
DEBUG: Checking if file /tmp/vpp-lib-17.04-rc0~359_g077d6ae~b1983.x86_64.rpm 
exists
DEBUG: Checking if file 
/tmp/vpp-plugins-17.04-rc0~359_g077d6ae~b1983.x86_64.rpm exists
DEBUG: Starting VIRL topology
...
DEBUG: Upgrading VPP
DEBUG: Upgrading VPP on node 10.30.51.211
DEBUG: Installing RPM packages
DEBUG: Command output was:
Preparing...  

DEBUG: Command stderr was:
   file /usr/include/dpdk conflicts between attempted installs of 
vpp-dpdk-devel-17.02-vpp1.x86_64 and 
vpp-devel-17.04-rc0~359_g077d6ae~b1983.x86_64

DEBUG: Upgrading VPP on node 10.30.51.212
DEBUG: Installing RPM packages
DEBUG: Command output was:
Preparing...  

DEBUG: Command stderr was:
   file /usr/include/dpdk conflicts between attempted installs of 
vpp-dpdk-devel-17.02-vpp1.x86_64 and 
vpp-devel-17.04-rc0~359_g077d6ae~b1983.x86_64


so no VPP is installed...

Could you, please, help us to solve the issue?
Right now, I am working on resolving issue with RPM packaging when building 
outside of git repo either from gzip tarball or srpm. Nex

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

2017-03-08 Thread Steven Luong (sluong)

Maxime,

First of all, thank you very much for your detailed analysis and pinpoint
the possible problem area. Is it fair for me to ask the question that when
the client processes the message VHOST_USER_GET_VRING_BASE, it must
respond it with the existing last_avail_idx but not 0? I could not find
any document about this except this statement in the url

Client must start ring upon receiving a kick (that is, detecting that file
  
  
descriptor is readable) on the descriptor specified by
  
  
VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
  
  
VHOST_USER_GET_VRING_BASE.


https://github.com/qemu/qemu/blob/master/docs/specs/vhost-user.txt

As you see, the spec only mentions stop the ring, but nothing about the
last_avail_idx.
If you know where the spec/document says that the client must respond it
with the existing last_avail_idx, please point me to read about it.

Steven

On 3/8/17, 8:10 AM, "Maxime Coquelin"  wrote:

>Steven,
>
>On 03/08/2017 04:44 PM, Steven Luong (sluong) wrote:
>> Maxime,
>>
>> Last I heard csit uses qemu 2.5. Could you please check if the
>> aforementioned patch exists in that qemu version?
>In upstream QEMU, the patch landed into v2.7.0 tag, so if you are using
>upstream version then the patch is not there.
>
>Regards,
>Maxime
>
>>
>> Steven
>>
>> On 3/8/17, 7:36 AM, "vpp-dev-boun...@lists.fd.io on behalf of Maxime
>> Coquelin" > maxime.coque...@redhat.com> wrote:
>>
>>> Tom,
>>>
>>> On 03/08/2017 03:59 PM, Thomas F Herbert wrote:
 Maxime,

 The

 OK. Thanks. I am forwarding this to Pierre as he has been working on
 vhost-user.

 I thought we were now using dpdk's vhost-user driver as of 17.01.
>>> No it isn't.
>>> I would be interested in the reasons not doing the move, and propose my
>>> help if this is in VPP project plans.
>>>

 It is interesting how we haven't seen this in our csit testing and we
 are testing multi-queue. Also will this manifest only on certain
 revisions of Qemu/KVM?
>>>
>>> My understanding is:
>>> Before VPP 17.01, migration was fine whatever the QEMU version.
>>> The bug has been introduced in VPP 17.01 in commit e21c5286. From this
>>> commit, VPP will always reply 0 to GET_VRING_BASE whatever the real
>>> last_avail_idx value.
>>>
>>> But, depending on QEMU version, the problem will or won't be detected.
>>> If QEMU doesn't contain commit "virtio: recalculate vq->inuse after
>>> migration", then the bug will be silent and last_avail_idx will be
>>> wrongly restored in destination backend.
>>> If QEMU contains this patch, problem is detected and migration fails.
>>>
>>> Do you know which QEMU version you are using in your CSIT testing?
>>> I can check whether it contains this patch.
>>>
>>> Regards,
>>> Maxime

 --TFH

  Forwarded Message 
 Subject:   [Bug 1422534] vdev->vq[i] .used_idx does not consider the
 right value for vhostuser
 Date:  Wed, 08 Mar 2017 08:56:49 +
 From:  bugzi...@redhat.com
 To:therb...@redhat.com



 https://bugzilla.redhat.com/show_bug.cgi?id=1422534



 --- Comment #27 from Maxime Coquelin  ---
 Tom,

 I had a look at mainline VPP:
 $ build-root/scripts/version
 17.04-rc0~382-ga0b34a7

 Looking at 16.06 release, it seems to be a regression, as the vring
 struct is
 not reset before getting last_avail_idx, only the enable bit is
cleared:

 case VHOST_USER_GET_VRING_BASE:
   DBG_SOCK("if %d msg VHOST_USER_GET_VRING_BASE idx %d num %d",
 vui->hw_if_index, msg.state.index, msg.state.num);

   /* Spec says: Client must [...] stop ring upon receiving
 VHOST_USER_GET_VRING_BASE. */
   vui->vrings[msg.state.index].enabled = 0;

   msg.state.num = vui->vrings[msg.state.index].last_avail_idx;
   msg.flags |= 4;
   msg.size = sizeof(msg.state);
   break;

 The regression seems to have been introduced by below commit, which
 landed into
 v17.01 release:

 $  git blame src/vnet/devices/virtio/vhost-user.c -L 1031
 e21c5286 vnet/vnet/devices/virtio/vhost-user.c (Pierre Pfister
 2016-09-21
 08:04:59 +0100 1031)   vhost_user_vring_close (vui,
 msg.state.index);

 $ git show e21c5286
 commit e21c52861d7c503bef7fc464f23bbc7891e150d7
 Author: Pierre Pfister 
 Date:   Wed Sep 21 08:04:59 2016 +0100

 vhost-user: multiqueue support

 This patch adds multi-queue support to non-dpdk's vhost-user
 driver.
 Waiting for a unified way to manage threads, this patch
 defines a way to assign threads to interfaces that is
 specific to vhost.

 Change-Id: I86298788b1a4e886c5431f187dc17175d12c7a8b
 Signed-off-by: Pierre Pfister 

 $ git tag --contains e21c5286
 v17.01
 v17.0

[vpp-dev] Problem building from source tarball without git

2017-03-08 Thread Thomas F Herbert

I have been working on a patch to build a SRPM for downstream packaging 
but ran into a problem and need more eyes.


This is dependent on my earlier patch for building a dist tarball 
20a29c7b4d1b5b68112498bee21ee7f3fe123b13 which encapsulates the version 
metadata in a .version file in build-root/scripts. The version metadata 
can be determined from within the tarball when there is no git which is 
done by executing build-root/scripts/version which will work with or 
without git.


See JIRA-498

However, now, this is broken by newer build changes which generates a 
different .version in build-root/build-vpp-native/vpp and this .version 
is used to construct the file version.h which is a dependency for the 
builds to work.


I looked at src/vpp.am and it "looks like" the .version target should 
work because of:

VPP_VERSION = $(shell $(srcdir)/scripts/version)
but I think that it should check for a non zero exit code from git 
rev-parse.




Steps to reproduce

$ cd tmp

$ git clone 

$ cd vpp

$ make dist

$ cd ..

$ xzf ../vpp/build-root/rpm/vpp-17.04-rc0~395_gd96bad8.tar.gz

$ cd vpp-17.04

$ make bootstrap

$ make build-release

...
CC   vpp/vnet/bin_vpp-main.o
/home/therbert/tmp/dist/vpp-17.04/build-data/../src/vpp/vnet/main.c:21:29: 
fatal error: vpp/app/version.h: No such file or directory

compilation terminated.

Full results in 
https://gist.github.com/tfherbert/3e26ab4ce8989ba35158573ccc641591


Thanks for looking at this.
--
*Thomas F Herbert*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

2017-03-08 Thread John Lo (loj)

Hi Matej,

The difference between having an interface in L2 bridge/xconnect mode is that 
the interface is put into promiscuous mode. Thus the interface will receive all 
packets irrespective of its destination MAC address. When an interface is in L3 
mode, it will receive packets with DMAC matching that of its own MAC only. 
Also, in L3 mode, packets with VLAN must match a sub-interface which you did 
not setup. I wonder whether it is the case that the virtio driver is smart 
enough to not accept VLAN packets in non-promiscuous mode also. One way to test 
can be to create a sub-interface matching VLAN 3 and check how it behaves.

Regards,
John


From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, March 08, 2017 8:43 AM
To: vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

Hi all,

I did some test in virl testbed. I sent following 3 frames to VPP interface 
from scapy:
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', 
dst='fa:16:3e:d0:4a:66')/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x8100)/Dot1Q(vlan=10)/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x)/IP())


In vpp_api_test I ran:
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up

exec show trace, it shows no Dot1Q frame
--- Start of thread 0 vpp_main ---
Packet 1

00:00:24:982426: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 14, length 20, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982450: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982460: ip4-lookup
  fib 0 dpo-idx 0 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982464: ip4-drop
IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
  tos 0x00, ttl 64, length 20, checksum 0x7ce7
  fragment id 0x0001
00:00:24:982467: error-drop
  ip4-input: ip4 adjacency drop

Packet 2

00:00:25:003176: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ddc: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33600
packet_type 0x0
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003179: ethernet-input
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003183: error-punt
  dpdk-input: no error


When I added the interface to a bridge domain there are 3 captured packets
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up
sw_interface_set_l2_bridge sw_if_index 1 bd_id 1 shg 0 enable
vat# exec show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:28:944099: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:28:944119: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:28:944127: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:00:28:944129: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944134: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944137: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944138: error-drop
  l2-flood: L2 replication complete

Packet 2

00:00:28:953150: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ddc: current data 0, length 38, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x0, data_off 128, phys_addr 0x4fd33600
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66 802.1q vlan 10
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:28:953153: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66 802.1q vlan 10
00:00:28:953155: l2-input
  l2-

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

2017-03-08 Thread John Lo (loj)

If adding a sub-interface for VLAN 3 still does not work, try create another 
dummy sub-interface with, say VLAN 100, and put that sub-interface into a 
bridge domain. This will force the interface into promiscuous mode.  -John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of John Lo (loj)
Sent: Wednesday, March 08, 2017 9:45 PM
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

Hi Matej,

The difference between having an interface in L2 bridge/xconnect mode is that 
the interface is put into promiscuous mode. Thus the interface will receive all 
packets irrespective of its destination MAC address. When an interface is in L3 
mode, it will receive packets with DMAC matching that of its own MAC only. 
Also, in L3 mode, packets with VLAN must match a sub-interface which you did 
not setup. I wonder whether it is the case that the virtio driver is smart 
enough to not accept VLAN packets in non-promiscuous mode also. One way to test 
can be to create a sub-interface matching VLAN 3 and check how it behaves.

Regards,
John


From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, March 08, 2017 8:43 AM
To: vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

Hi all,

I did some test in virl testbed. I sent following 3 frames to VPP interface 
from scapy:
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', 
dst='fa:16:3e:d0:4a:66')/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x8100)/Dot1Q(vlan=10)/IP())
sendp(iface='ens6', x=Ether(src='02:00:00:00:00:02', dst='fa:16:3e:d0:4a:66', 
type=0x)/IP())


In vpp_api_test I ran:
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up

exec show trace, it shows no Dot1Q frame
--- Start of thread 0 vpp_main ---
Packet 1

00:00:24:982426: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 14, length 20, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982450: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982460: ip4-lookup
  fib 0 dpo-idx 0 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:24:982464: ip4-drop
IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
  tos 0x00, ttl 64, length 20, checksum 0x7ce7
  fragment id 0x0001
00:00:24:982467: error-drop
  ip4-input: ip4 adjacency drop

Packet 2

00:00:25:003176: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ddc: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33600
packet_type 0x0
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003179: ethernet-input
  0x: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:25:003183: error-punt
  dpdk-input: no error


When I added the interface to a bridge domain there are 3 captured packets
exec trace add dpdk-input 10
sw_interface_set_flags sw_if_index 1 admin-up
sw_interface_set_l2_bridge sw_if_index 1 bd_id 1 shg 0 enable
vat# exec show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:28:944099: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x4fd33fc0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:00:28:944119: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:d0:4a:66
00:00:28:944127: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:00:28:944129: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944134: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:944137: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28

Re: [vpp-dev] VPP on raspberry pi & 32 bit compilation

2017-03-08 Thread Burt Silverman

I thought the RP 3 Model B is a 64 bit machine.

   - A 1.2GHz 64-bit quad-core ARMv8 CPU

Is the build done directly on the RP, or is it done via cross compilation?
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] R Signal events between graph nodes within different threads

2017-03-08 Thread Xu, Xiyun

Do be a little confusion.  AFAIK, the original question from ZTE, key message 
should be:   so we want to transfer some packet to main thread to continue 
processing

Is this right, @ZTE wanghui

which kind of scenario you want to pass the pkt from work thread to main 
thread. Although the pkt is already processed by work thread and still need to 
put it to main thread for further processing?
What’s your real case☺

Did you consider the handoff mechanism before? But it seems to pkt queuing btw 
two different work threads

Thanks.
Regards

BTW:
In my understanding,  Hongjun and ZTE guys mentions following two ways

(1)vlib_process_signal_event



it seems to be just pass the event/message(Event type + opaque data) to process 
nodes which belong to main threads, instead of passing pkt from worker thread 
to main thread.
It is asynchronous way.


(2)vl_api_rpc_call_main_thread



it is synchronous method to call the RPC function belongs to main thread 
context, seems to be also not pkt passing btw two threads.

Let Dave and Damjan to correct me☺. Thanks!

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Dave Barach (dbarach)
Sent: Wednesday, March 8, 2017 9:47 PM
To: wang.hu...@zte.com.cn; Ni, Hongjun ; Damjan Marion 
(damarion) 
Cc: vpp-dev@lists.fd.io; gu.ji...@zte.com.cn; zhao.zhig...@zte.com.cn; 
pan.feng...@zte.com.cn
Subject: Re: [vpp-dev] R Signal events between graph nodes within different 
threads

Guys,

Oh, you want the main thread to process packets? Why didn’t you simply ask how 
to do that in the first place?

At worst, a few lines’ worth of code - to enable e.g. dpdk-input in thread-0 - 
might be required. Copying Damjan.

Thanks… Dave

From: wang.hu...@zte.com.cn 
[mailto:wang.hu...@zte.com.cn]
Sent: Wednesday, March 8, 2017 2:50 AM
To: hongjun...@intel.com
Cc: alaga...@gmail.com; Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>; 
zhao.zhig...@zte.com.cn; 
gu.ji...@zte.com.cn; 
pan.feng...@zte.com.cn; 
vpp-dev@lists.fd.io
Subject: 答复: RE: R[vpp-dev] Signal events between graph nodes within different 
threads


Yes, I realize that, it could be work. Thanks to hongjun.

But vl_api_rpc_call_main_thread will degrade packet handling performance in 
worker thread, I don't know if there is a common and high performance way to do 
this?

And also  I guess vlib_process_signal_event can only be used in main thread? 
just my opinion, since I have not gone deep into the signal event code.





王辉 wanghui



IT开发工程师 IT Development Engineer
虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D 
Institute/Wireless Product Operation Division
原始邮件
发件人： ＜hongjun...@intel.com＞;
收件人：王辉10067165; ＜alaga...@gmail.com＞;
抄送人： ＜dbar...@cisco.com＞;赵志刚10017628;顾剑10036178;潘凤艳00024606; 
＜vpp-dev@lists.fd.io＞;
日 期 ：2017年03月08日 15:18
主 题 ：RE: R[vpp-dev]  Signal events between graph nodes within different threads


Hi Hui,

I think the SNAT example maybe meet what you want:

snat_in2out_node_fn_inline: (in worker thread)
 slow_path
snat_ipfix_logging_nat44_ses_create
vl_api_rpc_call_main_thread

Regards,
Hongjun

From: wang.hu...@zte.com.cn 
[mailto:wang.hu...@zte.com.cn]
Sent: Wednesday, March 8, 2017 2:58 PM
To: alaga...@gmail.com
Cc: dbar...@cisco.com; Ni, Hongjun 
＜hongjun...@intel.com＞; 
zhao.zhig...@zte.com.cn; 
gu.ji...@zte.com.cn; 
pan.feng...@zte.com.cn; 
vpp-dev@lists.fd.io
Subject: 答复: Re: [vpp-dev] 答复: Re: Signal events between graph nodes within 
different threads


Maybe if you could expand on what it is you are trying to achieve?

//when starting worker thread ,  the main thread can't receive packet from IO, 
so we want to transfer some packet to main thread to continue processing.



Is it specifically to do with DHCP (and proxy) or is that just the code you 
found that looks like the kind of functionality you believe you need for your 
use-case?

// that just looks like our use-case. vlib_process_signal_event called in 
worker thread, and signal an event to the dhcp proccess node in main thread.

can  vlib_process_signal_event  do this?









王辉 wanghui



IT开发工程师 IT Development Engineer
虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D  
Institute/Wireless Product Operation Division
原始邮件
发件人： ＜alaga...@gmail.com＞;
收件人：王辉10067165; ＜dbar...@cisco.com＞; ＜hongjun...@intel.com＞;
抄送人：赵志刚10017628;顾剑10036178;潘凤艳00024606; ＜vpp-dev@lists.fd.io＞;
日 期 ：2017年03月08日  13:04
主 题 ：Re: [vpp-dev] 答复: Re: Signal events between graph nodes within different 
threads



On Wed, Mar 8, 2017 at 2:29 PM 
＜wang.hu...@zte.com.

Re: [vpp-dev] Missing lib pneum during build?

Re: [vpp-dev] issues when enable proxy-arp

Re: [vpp-dev] raspberrypi builds

Re: [vpp-dev] issues when enable proxy-arp

Re: [vpp-dev] raspberrypi builds

Re: [vpp-dev] VPP on raspberry pi & 32 bit compilation

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

Re: [vpp-dev] R Signal events between graph nodes within different threads

[vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

[vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

Re: [vpp-dev] fd.io CSIT vhost-user test scenario implementation priorities

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

[vpp-dev] dpdk input-node fixed sleep => low load average on my vpp home gateway

Re: [vpp-dev] [Dev question on changing the VLIB_FRAME_SIZE]

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

Re: [vpp-dev] [csit-dev] installation issue of release rpm packages from Nexus on centos7 system

Re: [vpp-dev] Fwd: [Bug 1422534] vdev->vq[i] .used_idx does not consider the right value for vhostuser

[vpp-dev] Problem building from source tarball without git

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

Re: [vpp-dev] VPP on raspberry pi & 32 bit compilation

Re: [vpp-dev] R Signal events between graph nodes within different threads

25 matches

Site Navigation

Mail list logo

Footer information