date:20170127

Re: [vpp-dev] Can't map NSH entry in VPP

2017-01-27 Thread Dave Barach (dbarach)

Dear Miguel,

Here's another trick: "pcap drop trace on max 100 intfc " - 
send pkts - "pcap drop trace off".

This will create a pcap trace of packets received on  which were 
dropped, in /tmp/drop.pcap.

It sure looks like this will capture the nsh packets inquestion, so you can 
check them in Wireshark; to the extent that you don't already know what's 
wrong...

Thanks... Dave

From: Miguel Angel Muñoz Gonzalez 
[mailto:miguel.angel.munoz.gonza...@ericsson.com]
Sent: Friday, January 27, 2017 4:41 PM
To: Dave Barach (dbarach) ; nsh_sfc-...@lists.fd.io; 
vpp-dev@lists.fd.io
Subject: RE: Can't map NSH entry in VPP

Thanks Dave, this really helped me (I used the pcap tx trace before but your 
suggestion offers much more information).
Below is the info I got. It shows that the nsh-input gets wrong values and it 
matches what I see with wireshark. However the ovs-dpctl dump-flows in 
CLASSIFIER1 shows completely different information, as shown in previous mail. 
It looks like OVS is not encoding the message correctly.

Packet 45
00:27:47:102658: dpdk-input
  GigabitEthernet0/9/0 rx queue 0
  buffer 0x426f: current data 0, length 162, free-list 0, totlen-nifb 0, trace 
0x2c
  PKT MBUF: port 0, nb_segs 1, pkt_len 162
buf_len 2176, data_len 162, ol_flags 0x0, data_off 128, phys_addr 0x746cf2c0
packet_type 0x0
  IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102748: ethernet-input
  IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
00:27:47:102760: ip4-input
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102763: ip4-lookup
  fib 0 adj-idx 4 :  192.168.70.20/24 flow hash: 0x
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102767: ip4-local
UDP: 192.168.70.10 -> 192.168.70.20
  tos 0x00, ttl 64, length 148, checksum 0x85b5
  fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
  length 128, checksum 0x
00:27:47:102770: ip4-udp-lookup
  UDP: src-port 33124 dst-port 4790
00:27:47:102774: vxlan4-gpe-input
  VXLAN-GPE: no tunnel next 4 error 1

00:27:47:102778: nsh-input

  nsh ver 0 len 0 (0 bytes) md_type 0 next_protocol 0
  service path 15763460 service index 54
  c1 -1257065167 c2 100683657 c3 769 c4 -1463746792

00:27:47:102789: error-drop
  nsh-input: no mapping for nsh key

Thank you very much,
Best Regards,
Miguel Ángel Muñoz.


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: viernes, 27 de enero de 2017 18:21
To: Miguel Angel Muñoz Gonzalez 
mailto:miguel.angel.munoz.gonza...@ericsson.com>>;
 nsh_sfc-...@lists.fd.io; 
vpp-dev@lists.fd.io
Subject: RE: Can't map NSH entry in VPP

Please see if vpp packet tracer will show you why the packets aren't behaving 
as required...

For example:

Vpp# trace add dpdk-input 50

Vpp# show trace

HTH... Thanks... Dave

P.S. you might need to specify a node other than dpdk-input if e.g. you're 
using tap, af_packet, etc. other sorts of interfaces.

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Miguel Angel Muñoz Gonzalez
Sent: Friday, January 27, 2017 11:34 AM
To: nsh_sfc-...@lists.fd.io; 
vpp-dev@lists.fd.io
Subject: [vpp-dev] Can't map NSH entry in VPP

Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with 
this setup:


  +-+
   | Host (ODL SFC)  |
   |  192.168.60.1   |
   +-+
   /  |  | \
/ |  | \
/ |  | \
+---+  +--+   +--+  +---+
|  classifier1  |  |sff1  |   | sff2 |  |  classifier2  |
| 192.168.60.10 |  |192.168.60.20 |   |192.168.60.50 |  | 192.168.60.60 |
+---+  +--+   +--+  +---+
  |  |
  |  |
   +---+  +--+
   |  sf1(DPI-1)   |  |   sf2(FW-1)  |
   |192.168.60.30  |  |192.168.60.40 |
   +---+  +--+

In the Classifiers I am running OVS and VPP in the SFFs. My intention is to 
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to 
gbp-sfc demo).
I

Re: [vpp-dev] Can't map NSH entry in VPP

2017-01-27 Thread Ni, Hongjun

Hi Miguel,

Yes, you are right. C1,C2,C3 and C4 are not part of NSH key.

Could you capture the packet sent from CLASSIFIER1?
Or using packet trace in VPP to see what the real packet contains?
That would be helpful.

Thanks,
Hongjun

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Miguel Angel Muñoz Gonzalez
Sent: Saturday, January 28, 2017 12:34 AM
To: nsh_sfc-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [vpp-dev] Can't map NSH entry in VPP

Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with 
this setup:


  +-+
   | Host (ODL SFC)  |
   |  192.168.60.1   |
   +-+
   /  |  | \
/ |  | \
/ |  | \
+---+  +--+   +--+  +---+
|  classifier1  |  |sff1  |   | sff2 |  |  classifier2  |
| 192.168.60.10 |  |192.168.60.20 |   |192.168.60.50 |  | 192.168.60.60 |
+---+  +--+   +--+  +---+
  |  |
  |  |
   +---+  +--+
   |  sf1(DPI-1)   |  |   sf2(FW-1)  |
   |192.168.60.30  |  |192.168.60.40 |
   +---+  +--+

In the Classifiers I am running OVS and VPP in the SFFs. My intention is to 
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to 
gbp-sfc demo).
I can send out a packet from CLASSIFIER1 towards SFF1. However when it gets to 
the SFF1 it cannot apply correctly the NSH rules to route it to the next step 
(SF1).
As you can see, there is a packet going out from CLASSIFIER1 (with OVS):

vagrant@classifier1:~$ sudo ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=00:00:00:00:35:02,dst=88:f0:31:b5:12:b5),eth_type(0x0800),ipv4(src=10.0.35.2,dst=10.0.36.5,proto=6,tos=0/0x3,ttl=64,frag=no),
tcp(dst=80), packets:0, bytes:0, used:never, 
actions:set(tunnel(tun_id=0x3,dst=192.168.70.20,ttl=64,tp_dst=4790,vxlan(gpe(np=0x4,flags=0)),flags(df|key))),
set(eth(src=88:f0:31:b5:12:b5,dst=00:00:00:00:36:05)),set(ipv4(src=10.0.35.2,dst=10.0.36.5,tos=0/0x3,ttl=63)),
push_nsh(encap_eth_src=88:f0:31:b5:12:b5,encap_eth_dst=00:00:00:00:36:05,encap_eth_type=0x894f,
nsh_mdtype=1,nsh_np=3,nsp=44,nsi=255,nshc1=3232250940,nshc2=3,nshc3=0,nshc4=0),2

However VPP in SFF1 cannot forward the packet and actually increases the nsh 
error counter:

vagrant@sff1:~$ sudo vppctl show error
   CountNode  Reason
   573nsh-input   no mapping for nsh key
12ip6-input   ip6 source lookup miss
 3 ip6-icmp-input neighbor solicitations for 
unknown targets
18 ip6-icmp-input neighbor discovery not 
configured
   104arp-input   ARP replies sent
 6arp-input   ARP replies received

And I cannot find the fault since the entries in nsh for VPP in SFF1 seem to be 
correct:

vagrant@sff1:~$ sudo vppctl show nsh map
nsh entry nsp: 44 nsi: 255 maps to nsp: 44 nsi: 255 encapped by VXLAN GPE intf: 
2
nsh entry nsp: 44 nsi: 254 maps to nsp: 44 nsi: 254 encapped by VXLAN GPE intf: 
3
nsh entry nsp: 8388652 nsi: 254 maps to nsp: 8388652 nsi: 254 encapped by VXLAN 
GPE intf: 2
nsh entry nsp: 8388652 nsi: 253 maps to nsp: 8388652 nsi: 253 encapped by VXLAN 
GPE intf: 4

vagrant@sff1:~$ sudo vppctl show nsh entry
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 255
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 253
  c1 1 c2 9 c3 3 c4 4
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 45 service index 255
  c1 -1062716356 c2 3 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 250
  c1 -1062716356 c2 3 c3 0 c4 0
vagrant@sff1:~$

The only reason I can think of is that c1,c2,c3 and c4 are not 0,0,0,0 (as 
shown in the nsh entries). But these fields are not part of the nsh key that is 
used to find the proper nsh rule, are they?

I would appreciate if someone could provide a hint about the problem.

Thank you very much,
Best Regards,
Miguel Ángel Muñoz.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Can't map NSH entry in VPP

2017-01-27 Thread Miguel Angel Muñoz Gonzalez

Thanks Dave, this really helped me (I used the pcap tx trace before but your 
suggestion offers much more information).
Below is the info I got. It shows that the nsh-input gets wrong values and it 
matches what I see with wireshark. However the ovs-dpctl dump-flows in 
CLASSIFIER1 shows completely different information, as shown in previous mail. 
It looks like OVS is not encoding the message correctly.

Packet 45
00:27:47:102658: dpdk-input
  GigabitEthernet0/9/0 rx queue 0
  buffer 0x426f: current data 0, length 162, free-list 0, totlen-nifb 0, trace 
0x2c
  PKT MBUF: port 0, nb_segs 1, pkt_len 162
buf_len 2176, data_len 162, ol_flags 0x0, data_off 128, phys_addr 0x746cf2c0
packet_type 0x0
  IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102748: ethernet-input
  IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
00:27:47:102760: ip4-input
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102763: ip4-lookup
  fib 0 adj-idx 4 :  192.168.70.20/24 flow hash: 0x
  UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
  UDP: 33124 -> 4790
length 128, checksum 0x
00:27:47:102767: ip4-local
UDP: 192.168.70.10 -> 192.168.70.20
  tos 0x00, ttl 64, length 148, checksum 0x85b5
  fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
  length 128, checksum 0x
00:27:47:102770: ip4-udp-lookup
  UDP: src-port 33124 dst-port 4790
00:27:47:102774: vxlan4-gpe-input
  VXLAN-GPE: no tunnel next 4 error 1

00:27:47:102778: nsh-input

  nsh ver 0 len 0 (0 bytes) md_type 0 next_protocol 0
  service path 15763460 service index 54
  c1 -1257065167 c2 100683657 c3 769 c4 -1463746792

00:27:47:102789: error-drop
  nsh-input: no mapping for nsh key

Thank you very much,
Best Regards,
Miguel Ángel Muñoz.


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: viernes, 27 de enero de 2017 18:21
To: Miguel Angel Muñoz Gonzalez ; 
nsh_sfc-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: RE: Can't map NSH entry in VPP

Please see if vpp packet tracer will show you why the packets aren't behaving 
as required...

For example:

Vpp# trace add dpdk-input 50

Vpp# show trace

HTH... Thanks... Dave

P.S. you might need to specify a node other than dpdk-input if e.g. you're 
using tap, af_packet, etc. other sorts of interfaces.

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Miguel Angel Muñoz Gonzalez
Sent: Friday, January 27, 2017 11:34 AM
To: nsh_sfc-...@lists.fd.io; 
vpp-dev@lists.fd.io
Subject: [vpp-dev] Can't map NSH entry in VPP

Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with 
this setup:


  +-+
   | Host (ODL SFC)  |
   |  192.168.60.1   |
   +-+
   /  |  | \
/ |  | \
/ |  | \
+---+  +--+   +--+  +---+
|  classifier1  |  |sff1  |   | sff2 |  |  classifier2  |
| 192.168.60.10 |  |192.168.60.20 |   |192.168.60.50 |  | 192.168.60.60 |
+---+  +--+   +--+  +---+
  |  |
  |  |
   +---+  +--+
   |  sf1(DPI-1)   |  |   sf2(FW-1)  |
   |192.168.60.30  |  |192.168.60.40 |
   +---+  +--+

In the Classifiers I am running OVS and VPP in the SFFs. My intention is to 
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to 
gbp-sfc demo).
I can send out a packet from CLASSIFIER1 towards SFF1. However when it gets to 
the SFF1 it cannot apply correctly the NSH rules to route it to the next step 
(SF1).
As you can see, there is a packet going out from CLASSIFIER1 (with OVS):

vagrant@classifier1:~$ sudo ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=00:00:00:00:35:02,dst=88:f0:31:b5:12:b5),eth_type(0x0800),ipv4(src=10.0.35.2,dst=10.0.36.5,proto=6,tos=0/0x3,ttl=64,frag=no),
tcp(dst=80), packets:0, bytes:0, used:never, 
actions:set(tunnel(tun_id=0x3,dst=192.168.70.20,ttl=64,tp_dst=4790,vxlan(gpe(np=0x4,flags=0)),flags(df|key))),
set(eth(src=88:f0:31:b5:12:b5,dst=00:00:00:00:36:05)),set(ipv4(src=10.0.35.2,dst=10.0.36.5,tos=0/0x3,ttl=63)),
push_nsh(encap_eth_s

Re: [vpp-dev] Can't map NSH entry in VPP

2017-01-27 Thread Dave Barach (dbarach)

Please see if vpp packet tracer will show you why the packets aren't behaving 
as required...

For example:

Vpp# trace add dpdk-input 50

Vpp# show trace

HTH... Thanks... Dave

P.S. you might need to specify a node other than dpdk-input if e.g. you're 
using tap, af_packet, etc. other sorts of interfaces.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Miguel Angel Muñoz Gonzalez
Sent: Friday, January 27, 2017 11:34 AM
To: nsh_sfc-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [vpp-dev] Can't map NSH entry in VPP

Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with 
this setup:


  +-+
   | Host (ODL SFC)  |
   |  192.168.60.1   |
   +-+
   /  |  | \
/ |  | \
/ |  | \
+---+  +--+   +--+  +---+
|  classifier1  |  |sff1  |   | sff2 |  |  classifier2  |
| 192.168.60.10 |  |192.168.60.20 |   |192.168.60.50 |  | 192.168.60.60 |
+---+  +--+   +--+  +---+
  |  |
  |  |
   +---+  +--+
   |  sf1(DPI-1)   |  |   sf2(FW-1)  |
   |192.168.60.30  |  |192.168.60.40 |
   +---+  +--+

In the Classifiers I am running OVS and VPP in the SFFs. My intention is to 
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to 
gbp-sfc demo).
I can send out a packet from CLASSIFIER1 towards SFF1. However when it gets to 
the SFF1 it cannot apply correctly the NSH rules to route it to the next step 
(SF1).
As you can see, there is a packet going out from CLASSIFIER1 (with OVS):

vagrant@classifier1:~$ sudo ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=00:00:00:00:35:02,dst=88:f0:31:b5:12:b5),eth_type(0x0800),ipv4(src=10.0.35.2,dst=10.0.36.5,proto=6,tos=0/0x3,ttl=64,frag=no),
tcp(dst=80), packets:0, bytes:0, used:never, 
actions:set(tunnel(tun_id=0x3,dst=192.168.70.20,ttl=64,tp_dst=4790,vxlan(gpe(np=0x4,flags=0)),flags(df|key))),
set(eth(src=88:f0:31:b5:12:b5,dst=00:00:00:00:36:05)),set(ipv4(src=10.0.35.2,dst=10.0.36.5,tos=0/0x3,ttl=63)),
push_nsh(encap_eth_src=88:f0:31:b5:12:b5,encap_eth_dst=00:00:00:00:36:05,encap_eth_type=0x894f,
nsh_mdtype=1,nsh_np=3,nsp=44,nsi=255,nshc1=3232250940,nshc2=3,nshc3=0,nshc4=0),2

However VPP in SFF1 cannot forward the packet and actually increases the nsh 
error counter:

vagrant@sff1:~$ sudo vppctl show error
   CountNode  Reason
   573nsh-input   no mapping for nsh key
12ip6-input   ip6 source lookup miss
 3 ip6-icmp-input neighbor solicitations for 
unknown targets
18 ip6-icmp-input neighbor discovery not 
configured
   104arp-input   ARP replies sent
 6arp-input   ARP replies received

And I cannot find the fault since the entries in nsh for VPP in SFF1 seem to be 
correct:

vagrant@sff1:~$ sudo vppctl show nsh map
nsh entry nsp: 44 nsi: 255 maps to nsp: 44 nsi: 255 encapped by VXLAN GPE intf: 
2
nsh entry nsp: 44 nsi: 254 maps to nsp: 44 nsi: 254 encapped by VXLAN GPE intf: 
3
nsh entry nsp: 8388652 nsi: 254 maps to nsp: 8388652 nsi: 254 encapped by VXLAN 
GPE intf: 2
nsh entry nsp: 8388652 nsi: 253 maps to nsp: 8388652 nsi: 253 encapped by VXLAN 
GPE intf: 4

vagrant@sff1:~$ sudo vppctl show nsh entry
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 255
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 253
  c1 1 c2 9 c3 3 c4 4
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 45 service index 255
  c1 -1062716356 c2 3 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 250
  c1 -1062716356 c2 3 c3 0 c4 0
vagrant@sff1:~$

The only reason I can think of is that c1,c2,c3 and c4 are not 0,0,0,0 (as 
shown in the nsh entries). But these fields are not part of the nsh key that is 
used to find the proper nsh rule, are they?

I would appreciate if someone could provide a hint about the problem.

Thank you very much,
Best Regards,
Miguel Ángel Muñoz.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://l

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

2017-01-27 Thread Burt Silverman

>>Only slightly :-)
Thank you, Christian. The one thing I don't know is whether there is
anybody on the list who feels that they need the module with the
CONFIG_VFIO_NOIOMMU set. Actually, I have a huge hole in my knowledge base
in the entire area of VFIO, UIO, IOMMU. But if there is interest in a
custom module at this time with that option set, I may have provided a
service: although my procedure has a number of steps, they are simple in
comparison to building a kernel that has a standard configuration. The
latter requires lots of disk space and lots of time.

>>I'm believing in the good of people and expect all misinformation to be
based on some case that worked for whoever wrote it in the past :-)
Yes, I have mischaracterized the situation a bit; my frustration was that I
invariably find the same use case, which is slightly different from what we
have here. The standard case that is addressed is essentially: you are
writing a custom module from scratch, it does not have any CONFIG_...
options in it, or at least, none that differ from the running kernel
.config. The other piece of information that I found misleading was the
idea expressed in /var/lib/dpkg/status for package linux-source-4.8.0

If you are simply trying to build third-party modules for your kernel,
 you do not want this package. Install the appropriate linux-headers
 package instead.

I still think I have a case where I want both linux-headers and
linux-source. So reading that WHILE I was struggling to figure out a
solution was further throwing me off the track.

I did attempt one simplification to my procedure: just work with the
linux-source package, and do the make menuconfig in its top directory, and
then do the kernel make command I showed earlier with the M= option. This
simpler procedure did not work; I believe there are a few extra "goodies"
in the linux-headers packages I needed.

Note that the steps of copying to my home directory keep the originals
pristine and allow me to work without being root.

Now I was not thorough earlier to check that CONFIG_VFIO_NOIOMMU or
VFIO_NOIOMMU does not show up in unexpected places that would lead to an
inconsistent kernel, but since then I grepped through all .c, .h, and
Kconfig* to verify. Looks good; things are limited to vfio.c.

Your DKMS method is probably the best, I have not tried it, but I don't
think it will directly handle the CONFIG option in vfio.c. Am I correct?
Perhaps a smarter approach than my first one is to modify vfio.c, and add
the line

#define CONFIG_VFIO_NOIOMMU 1

just below the existing #defines, and then use DKMS. If I can combine this
with getting the vfio.c source from the appropriate git repo, the only
manual effort is to occasionally do a git pull to pick up updates. Well,
not quite, but almost; it won't happen if I am locked to a tag. Anyway, my
earlier method was seeking the "graceful" meaning of elegance, rather than
the "simple" definition of elegance that occurs with simply adding the
#define to vfio.c.

I'll play around with DKMS and see if I can get results -- I have not used
DKMS enough.

Burt

On Fri, Jan 27, 2017 at 3:38 AM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
> On Thu, Jan 26, 2017 at 6:46 PM, Burt Silverman  wrote:
>
>> Thanks, Christian, this is great information.
>>
>> Just for fun, before I read this, I wanted to test some of my kernel
>> building skills. So I just wish to build modules in the drivers/vfio
>> directory. I want to do what might be called "building an external module"
>> or "building only one kernel module" as in http://askubuntu.com/questions
>> /515407/how-recipe-to-build-only-one-kernel-module or "building a third
>> party module". But the Google hits like that one assume that you have no
>> interest in changing the .config.
>>
>
> Is that "Building a module with a different kernel config than the kernel"?
> In that case that as so close to breaking it intentionally as possible :-)
>
>
>> And one Ubuntu package that may be useful, linux-source, has info showing
>> up in Synaptic saying "you don't want this package."
>>
>
> That is what you really want - https://wiki.ubuntu.com/
> Kernel/Dev/KernelGitGuide
> Maybe we should say this in the package - yet URLs tend to change ...
>
>
>> Here is my procedure and I hope it works -- it is relatively painless.
>> I'll describe it for a particular level. I am using the desktop version of
>> Ubuntu.
>>
> [...]
>
>> This is tricky stuff because there is plenty of non-information and
>> misinformation out there AND
>>
>
> IMHO it just is complex enough to confuse everybody more often than not
> (myself included if I haven't done it for a few weeks/months).
> I'm believing in the good of people and expect all misinformation to be
> based on some case that worked for whoever wrote it in the past :-)
> In that sense, yours likely will fail for many others AND even for you in
> a certain time int he future.
>
> [...]
>
>
>> Well, this stuff may be slightly off topic,
>

Re: [vpp-dev] Ping utility in VPP

2017-01-27 Thread Nagaprabhanjan Bellaru

Hi Andrew,

You observation is right. I was running vpp_lite with a buffer size of 512.
As you mentioned, defining PING_MAXIMUM_DATA_SIZE conditionally should work.

I have opened a jira ticket for this: https://jira.fd.io/browse/VPP-621

Thanks,
-nagp

On Fri, Jan 27, 2017 at 7:23 PM, Andrew 👽 Yourtchenko 
wrote:

> Hello,
>
> > On 27 Jan 2017, at 04:12, Nagaprabhanjan Bellaru 
> wrote:
> >
> > Hi,
> >
> > I am not sure if the ping debug CLI is being actively used, but the
> function "init_icmp46_echo_request" goes ahead and writes 2000 bytes into
> the vlib_buffer corrupting the surrounding memory area. After 3-4 pings,
> vpp always crashes.
>
> Could you please tell a bit more about the setup (which hypervisor, which
> make platform - vpp/vpp_lite, which ping etc) ? I had fixed a bug with
> processing a vector of replies (change 4844) - might be worth verifying you
> do not see the symptoms of that.
>
> Now, some thoughts below, please feel free to correct me if you find an
> error in the below logic.
>
> My understanding is we would get the 2048 bytes of max data size in DPDK
> case when allocating the buffer. Minus 20 bytes for IPv4 header, minus 4
> bytes for common ICMP header, minus 4 bytes for echo ID/seq, minus 8 bytes
> for the timestamp. That should give 2012 bytes of free space for data in
> IPv4 case, so for the IPv4 ping it should not overrun.
>
> The problem is of course in IPv6 case we are a few bytes short, and
> likewise in the vpp_lite case the VLIB_BUFFER_DATA_SIZE is 512, and we
> will overrun that with the static value of 2000.
>
> So the definition for PING_MAXIMUM_DATA_SIZE would need to depend on that
> define with appropriate  subtractions... or, even better, I suppose, is to
> use VLIB_BUFFER_DEFAULT_FREE_LIST_BYTES since that looks to me is the
> define determining the max data size for a buffer.
>
> Maybe an even better option could be to just fill a vector and then use
> the vlib_buffer_add_data() with zero buffer index, and let it allocate and
> set up everything behind the scenes.
>
> What do you think ?
>
> >
> > Instead of copying sizeof(icmp_echo_request->data) which is 2000, it we
> copy just data_len to the buffer, it should be fine?
>
> That would make the problem conditional on the CLI input for data size, so
> I would not say it is a much better outcome...
>
> --a
>
>
> >
> > Thanks,
> > -nagp
> > ___
> > 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-616 VPP Vagrant default box -> puppetlabs Ubuntu 16.04

2017-01-27 Thread Dave Wallace

FYI, I've backed out the change to build.sh to run "make test" instead 
of building the packages because vpp-csit-verify-master-virl uses this 
behavior to build the correct packages.


Thanks,
-daw-

On 01/26/2017 10:04 PM, Dave Wallace wrote:

Keith,

Please test the following patch for compatibility with your VMWare 
configuration: https://gerrit.fd.io/r/#/c/4897


@Damjan, I think that this should be cherry-picked to 17.01 since 
Ubuntu 14.04 is likely to deprecated.  What do you think?


Note: I also changed the default behavior to run "make test" instead 
of building the deb|rpm packages.


FYI, here is the commit message:
 %< 
Update default Vagrant box to Ubuntu 16.04, VPP-616

- Make puppetlabs/ubuntu-16.04-64-nocm the default box
- Enable x11 forwarding
- Install x11-utils required for emacs to work over X11
- Change default build to run "make test" instead of building packages

Change-Id: I0ec054fdc83feb71ca8396df53ed02bf82ecd7e7
Signed-off-by: Dave Wallace 
 %< 

Thanks,
-daw-


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

[vpp-dev] Can't map NSH entry in VPP

2017-01-27 Thread Miguel Angel Muñoz Gonzalez

Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with 
this setup:


  +-+
   | Host (ODL SFC)  |
   |  192.168.60.1   |
   +-+
   /  |  | \
/ |  | \
/ |  | \
+---+  +--+   +--+  +---+
|  classifier1  |  |sff1  |   | sff2 |  |  classifier2  |
| 192.168.60.10 |  |192.168.60.20 |   |192.168.60.50 |  | 192.168.60.60 |
+---+  +--+   +--+  +---+
  |  |
  |  |
   +---+  +--+
   |  sf1(DPI-1)   |  |   sf2(FW-1)  |
   |192.168.60.30  |  |192.168.60.40 |
   +---+  +--+

In the Classifiers I am running OVS and VPP in the SFFs. My intention is to 
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to 
gbp-sfc demo).
I can send out a packet from CLASSIFIER1 towards SFF1. However when it gets to 
the SFF1 it cannot apply correctly the NSH rules to route it to the next step 
(SF1).
As you can see, there is a packet going out from CLASSIFIER1 (with OVS):

vagrant@classifier1:~$ sudo ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=00:00:00:00:35:02,dst=88:f0:31:b5:12:b5),eth_type(0x0800),ipv4(src=10.0.35.2,dst=10.0.36.5,proto=6,tos=0/0x3,ttl=64,frag=no),
tcp(dst=80), packets:0, bytes:0, used:never, 
actions:set(tunnel(tun_id=0x3,dst=192.168.70.20,ttl=64,tp_dst=4790,vxlan(gpe(np=0x4,flags=0)),flags(df|key))),
set(eth(src=88:f0:31:b5:12:b5,dst=00:00:00:00:36:05)),set(ipv4(src=10.0.35.2,dst=10.0.36.5,tos=0/0x3,ttl=63)),
push_nsh(encap_eth_src=88:f0:31:b5:12:b5,encap_eth_dst=00:00:00:00:36:05,encap_eth_type=0x894f,
nsh_mdtype=1,nsh_np=3,nsp=44,nsi=255,nshc1=3232250940,nshc2=3,nshc3=0,nshc4=0),2

However VPP in SFF1 cannot forward the packet and actually increases the nsh 
error counter:

vagrant@sff1:~$ sudo vppctl show error
   CountNode  Reason
   573nsh-input   no mapping for nsh key
12ip6-input   ip6 source lookup miss
 3 ip6-icmp-input neighbor solicitations for 
unknown targets
18 ip6-icmp-input neighbor discovery not 
configured
   104arp-input   ARP replies sent
 6arp-input   ARP replies received

And I cannot find the fault since the entries in nsh for VPP in SFF1 seem to be 
correct:

vagrant@sff1:~$ sudo vppctl show nsh map
nsh entry nsp: 44 nsi: 255 maps to nsp: 44 nsi: 255 encapped by VXLAN GPE intf: 
2
nsh entry nsp: 44 nsi: 254 maps to nsp: 44 nsi: 254 encapped by VXLAN GPE intf: 
3
nsh entry nsp: 8388652 nsi: 254 maps to nsp: 8388652 nsi: 254 encapped by VXLAN 
GPE intf: 2
nsh entry nsp: 8388652 nsi: 253 maps to nsp: 8388652 nsi: 253 encapped by VXLAN 
GPE intf: 4

vagrant@sff1:~$ sudo vppctl show nsh entry
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 255
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 254
  c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 8388652 service index 253
  c1 1 c2 9 c3 3 c4 4
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 45 service index 255
  c1 -1062716356 c2 3 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
  service path 44 service index 250
  c1 -1062716356 c2 3 c3 0 c4 0
vagrant@sff1:~$

The only reason I can think of is that c1,c2,c3 and c4 are not 0,0,0,0 (as 
shown in the nsh entries). But these fields are not part of the nsh key that is 
used to find the proper nsh rule, are they?

I would appreciate if someone could provide a hint about the problem.

Thank you very much,
Best Regards,
Miguel Ángel Muñoz.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp build failure while creating rpm package

2017-01-27 Thread yusuf khan

Hi Gabriel,
Thanks. I have pulled lates from master and i can see your commit.
I will try it as soon as possible.

Regards,
Yusuf


On Fri, Jan 27, 2017 at 9:32 PM, Gabriel Ganne 
wrote:

> Hi Yusuf,
>
>
> I wrote a small patch which is supposed to take care of this issue :
> https://gerrit.fd.io/r/#/c/4894/
>
> I believe it was merged this morning.
>
>
> If you're not upstream, please pull and try again.
>
> Otherwise tell me so I'll look into what can cause this.
>
>
> Best regards,
>
>
> Gerrit Code Review 
> gerrit.fd.io
> ©2016 FD.io a Linux Foundation Collaborative Project. All Rights Reserved.
> Linux Foundation is a registered trademark of The Linux Foundation.
>
>
> Gabriel Ganne
> --
> *From:* vpp-dev-boun...@lists.fd.io  on
> behalf of yusuf khan 
> *Sent:* Friday, January 27, 2017 4:44:20 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] vpp build failure while creating rpm package
>
> Hi Team,
>
> I am able to build vpp on centos vm but it failes while creating the rpm
> package. with below error. All the dependencies are installed.
>
> ---
> Processing files: vpp-debuginfo-17.04-rc0~141_g1730077.x86_64
> Provides: vpp-debuginfo = 17.04-rc0~141_g1730077 vpp-debuginfo(x86-64) =
> 17.04-rc0~141_g1730077
> Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <=
> 3.0.4-1
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64
> error: Installed (but unpackaged) file(s) found:
>/usr/bin/dpdk-pdump
>/usr/bin/dpdk-pmdinfo
>/usr/bin/dpdk-procinfo
>/usr/bin/testpmd
>
>
> RPM build errors:
> File not found: /vpp/build-root/rpm/BUILDROOT/
> vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_plugins
> File not found: /vpp/build-root/rpm/BUILDROOT/
> vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_api_test_plugins
> Installed (but unpackaged) file(s) found:
>/usr/bin/dpdk-pdump
>/usr/bin/dpdk-pmdinfo
>/usr/bin/dpdk-procinfo
>/usr/bin/testpmd
> make[1]: *** [install-rpm] Error 1
> make[1]: Leaving directory `/vpp/build-root'
> make: *** [pkg-rpm] Error 2
> [vagrant@pktgen vpp]$ ls
>
> ---
>
>  The host OS is ubuntu 16.04.
> Just for information, debian package creation is successful on
> ubuntu-14.04 vm.
>
> Thanks in advance for help.
>
> Regards,
> Yusuf
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp build failure while creating rpm package

2017-01-27 Thread Gabriel Ganne

Hi Yusuf,


I wrote a small patch which is supposed to take care of this issue : 
https://gerrit.fd.io/r/#/c/4894/

I believe it was merged this morning.


If you're not upstream, please pull and try again.

Otherwise tell me so I'll look into what can cause this.


Best regards,


Gerrit Code Review
gerrit.fd.io
©2016 FD.io a Linux Foundation Collaborative Project. All Rights Reserved. 
Linux Foundation is a registered trademark of The Linux Foundation.




Gabriel Ganne


From: vpp-dev-boun...@lists.fd.io  on behalf of 
yusuf khan 
Sent: Friday, January 27, 2017 4:44:20 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp build failure while creating rpm package

Hi Team,

I am able to build vpp on centos vm but it failes while creating the rpm 
package. with below error. All the dependencies are installed.

---
Processing files: vpp-debuginfo-17.04-rc0~141_g1730077.x86_64
Provides: vpp-debuginfo = 17.04-rc0~141_g1730077 vpp-debuginfo(x86-64) = 
17.04-rc0~141_g1730077
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) 
<= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/bin/dpdk-pdump
   /usr/bin/dpdk-pmdinfo
   /usr/bin/dpdk-procinfo
   /usr/bin/testpmd


RPM build errors:
File not found: 
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_plugins
File not found: 
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_api_test_plugins
Installed (but unpackaged) file(s) found:
   /usr/bin/dpdk-pdump
   /usr/bin/dpdk-pmdinfo
   /usr/bin/dpdk-procinfo
   /usr/bin/testpmd
make[1]: *** [install-rpm] Error 1
make[1]: Leaving directory `/vpp/build-root'
make: *** [pkg-rpm] Error 2
[vagrant@pktgen vpp]$ ls

---

 The host OS is ubuntu 16.04.
Just for information, debian package creation is successful on ubuntu-14.04 vm.

Thanks in advance for help.

Regards,
Yusuf

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

[vpp-dev] vpp build failure while creating rpm package

2017-01-27 Thread yusuf khan

Hi Team,

I am able to build vpp on centos vm but it failes while creating the rpm
package. with below error. All the dependencies are installed.

---
Processing files: vpp-debuginfo-17.04-rc0~141_g1730077.x86_64
Provides: vpp-debuginfo = 17.04-rc0~141_g1730077 vpp-debuginfo(x86-64) =
17.04-rc0~141_g1730077
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <=
3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/bin/dpdk-pdump
   /usr/bin/dpdk-pmdinfo
   /usr/bin/dpdk-procinfo
   /usr/bin/testpmd


RPM build errors:
File not found:
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_plugins
File not found:
/vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_api_test_plugins
Installed (but unpackaged) file(s) found:
   /usr/bin/dpdk-pdump
   /usr/bin/dpdk-pmdinfo
   /usr/bin/dpdk-procinfo
   /usr/bin/testpmd
make[1]: *** [install-rpm] Error 1
make[1]: Leaving directory `/vpp/build-root'
make: *** [pkg-rpm] Error 2
[vagrant@pktgen vpp]$ ls

---

 The host OS is ubuntu 16.04.
Just for information, debian package creation is successful on ubuntu-14.04
vm.

Thanks in advance for help.

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

Re: [vpp-dev] SNAT Plugin Use

2017-01-27 Thread Dave Barach (dbarach)

That patch was the result of a less-than-optimal cleanup effort on my part. 
Until I did that, the plugins had their own copies of the M, M2, S, and W 
macros, each of which had some version of (VL_API_MUMBLE + plugin_msg_base).

I fucked up all of them in one motion when I got rid of N-1 cut-‘n-paste 
replicas of the M, M2, S, and W macros.

All of the csit tests passed - they use they Python language binding - nobody 
noticed until I got around to answering your email. I said several rude words 
you never read in the Bible, and set about fixing the problem.

Thanks… Dave

From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Friday, January 27, 2017 10:24 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] SNAT Plugin Use

On Thu, Jan 26, 2017 at 4:38 PM, Jon Loeliger 
mailto:j...@netgate.com>> wrote:

Does this same mechanism hold true for the VPE messages?  Is the collection
of the VPE message considered "a plugin", or "a base onto which plugins will
be added"?  There are currently 20 or 21 include files' worth of msg ids here.

Specifically, I'm trying to resolve an understanding of what I was told to do
last week (Use a msg_id based on a lookup of "_") versus this
use a msg_id obtained by "base + enum-value".

Is there a plugin name for the VPE collection of API msg ids?  (I don't think 
so.)
Will these msg_ids always be 0-based so no base offset need be looked-up
nor added?

Thanks,
jdl

Dave,

So, I feel like I may be a day late and a dollar short each time I ask
a question.  Like above.  So I just couldn't see where this base msg_id
addition was taking place...  And about the time I was trying to figure
it out, this commit happened:

author   Dave Barach mailto:d...@barachs.net>>
2017-01-25 16:32:08 -0500
commit 2d6b2d6d1bbb130921ec525a1cc6e88f42717c79 (patch)

Repair plugin binary API message numbering
Change-Id: I422a3f168bd483e011cfaf54af022cb79b78db02
Signed-off-by: Dave Barach mailto:d...@barachs.net>>

Which pretty much answers my question.

Are my questions the forcing function here? :-)
Or am I just on the bleeding edge?

jdl

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

Re: [vpp-dev] SNAT Plugin Use

2017-01-27 Thread Jon Loeliger

On Thu, Jan 26, 2017 at 4:38 PM, Jon Loeliger  wrote:
>
>
> Does this same mechanism hold true for the VPE messages?  Is the collection
> of the VPE message considered "a plugin", or "a base onto which plugins
> will
> be added"?  There are currently 20 or 21 include files' worth of msg ids
> here.
>
> Specifically, I'm trying to resolve an understanding of what I was told to
> do
> last week (Use a msg_id based on a lookup of "_") versus this
> use a msg_id obtained by "base + enum-value".
>
> Is there a plugin name for the VPE collection of API msg ids?  (I don't
> think so.)
> Will these msg_ids always be 0-based so no base offset need be looked-up
> nor added?
>
> Thanks,
> jdl
>

Dave,

So, I feel like I may be a day late and a dollar short each time I ask
a question.  Like above.  So I just couldn't see where this base msg_id
addition was taking place...  And about the time I was trying to figure
it out, this commit happened:

author Dave Barach  2017-01-25 16:32:08 -0500
commit 2d6b2d6d1bbb130921ec525a1cc6e88f42717c79 (patch)

Repair plugin binary API message numbering
Change-Id: I422a3f168bd483e011cfaf54af022cb79b78db02
Signed-off-by: Dave Barach 

Which pretty much answers my question.

Are my questions the forcing function here? :-)
Or am I just on the bleeding edge?

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

Re: [vpp-dev] Ping utility in VPP

2017-01-27 Thread Andrew 👽 Yourtchenko

Hello,

> On 27 Jan 2017, at 04:12, Nagaprabhanjan Bellaru  wrote:
> 
> Hi,
> 
> I am not sure if the ping debug CLI is being actively used, but the function 
> "init_icmp46_echo_request" goes ahead and writes 2000 bytes into the 
> vlib_buffer corrupting the surrounding memory area. After 3-4 pings, vpp 
> always crashes.

Could you please tell a bit more about the setup (which hypervisor, which make 
platform - vpp/vpp_lite, which ping etc) ? I had fixed a bug with processing a 
vector of replies (change 4844) - might be worth verifying you do not see the 
symptoms of that.

Now, some thoughts below, please feel free to correct me if you find an error 
in the below logic.

My understanding is we would get the 2048 bytes of max data size in DPDK case 
when allocating the buffer. Minus 20 bytes for IPv4 header, minus 4 bytes for 
common ICMP header, minus 4 bytes for echo ID/seq, minus 8 bytes for the 
timestamp. That should give 2012 bytes of free space for data in IPv4 case, so 
for the IPv4 ping it should not overrun.

The problem is of course in IPv6 case we are a few bytes short, and likewise in 
the vpp_lite case the VLIB_BUFFER_DATA_SIZE is 512, and we
will overrun that with the static value of 2000.

So the definition for PING_MAXIMUM_DATA_SIZE would need to depend on that 
define with appropriate  subtractions... or, even better, I suppose, is to use 
VLIB_BUFFER_DEFAULT_FREE_LIST_BYTES since that looks to me is the define 
determining the max data size for a buffer.

Maybe an even better option could be to just fill a vector and then use the 
vlib_buffer_add_data() with zero buffer index, and let it allocate and set up 
everything behind the scenes.

What do you think ?

> 
> Instead of copying sizeof(icmp_echo_request->data) which is 2000, it we copy 
> just data_len to the buffer, it should be fine?

That would make the problem conditional on the CLI input for data size, so I 
would not say it is a much better outcome...

--a

> 
> Thanks,
> -nagp
> ___
> 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] vpp make test for verify - are we there yet ? [awoken]

2017-01-27 Thread Neale Ranns (nranns)


Thanks Dave!

/neale

On 27/01/2017, 02:16, "Dave Wallace"  wrote:

Klement/Neale,

I finally got back to debugging this issue.  After doing a make 
test-wipe, then make test.  The patched python files and their 
corresponding .pyc files had the same timestamp with a 1-second 
resolution.  I deleted all .pyc files and then all of the tests passed.  
After doing some research, I confirmed that python uses a 1-second 
resolution when checking whether to recompile the *.pyc file.

I have verified that the following patch resolves this issue both on 
Ubuntu 16.04 in Vagrant and Ubuntu 16.10 on bare metal:

https://gerrit.fd.io/r/#/c/4896/

Thanks,
-daw-

On 01/05/2017 03:54 AM, Klement Sekera -X (ksekera - PANTHEON 
TECHNOLOGIES at Cisco) wrote:
> Dave, there is no sign of test framework installing/patching scapy in
> the log you provided.
>
> Could you please do in the same workspace
>
> make test-wipe
>
> and then run the make test again? I don't think it'll actually help us,
> because there should be no way for a python inside virtualenv to get its
> hands on outside libs (unless there is a bug of course), but let's see
> what happens...
>
> Thanks,
> Klement
>
> Quoting Dave Wallace (2017-01-04 19:19:04)
>> Neale,
>>
>> I could not find scapy installed in the normal path (i.e. "which 
scapy"),
>> but I'm not sure if it is directly executable.  You can find the "V=1
>> TEST=mpls make test" output on
>> vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin 
doc:
>> [1]http://pastebin.com/uGAUREhK
>>
>> Thanks,
>> -daw-
>>
>> On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote:
>>
>>
>>
>>   Hi,
>>
>>
>>
>>   The reason the MPLS tests are failing is because scapy cannot 
decode an
>>   MPLS label stack (output from some .show() instrumentation);
>>
>>
>>
>>   
>>
>>   ###[ Ethernet ]###
>>
>> dst   = 02:01:00:00:ff:02
>>
>> src   = 02:fe:e5:05:0e:13
>>
>> type  = 0x8847
>>
>>   ###[ MPLS ]###
>>
>>label = 33L
>>
>>cos   = 0L
>>
>>s = 0L   << NON End-of-stack
>>
>>ttl   = 254
>>
>>   ###[ Padding ]###
>>
>>   load  = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11
>>   
\xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257
>>   1 1'
>>
>>
>>
>>   we patch scapy for this purpose, see;
>>
>> /test/patches/scapy-2.3.3/mpls.py.patch
>>
>>
>>
>>   on my vagrant 14.04 there is no other scapy installation, this 
patch
>>   applies fine and all MPLS tests pass.
>>
>>   On a UCS 14.04, with another scapy installation:
>>
>> /usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py
>>
>>   the MPLS test fail.
>>
>>   On a UCS 16.04 no scpay installation, tests pass.
>>
>>
>>
>>   Do you have scapy installed in the machines on which the tests
>>   fail/pass? Or am I barking up the wrong virtualenv tree J
>>
>>
>>
>>   Thanks,
>>
>>   neale
>>
>>
>>
>>
>>
>>
>>
>> From: Dave Wallace [2]
>> Date: Wednesday, 4 January 2017 at 15:38
>> To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at 
Cisco)"
>> [3], "Maciek Konstantynowicz (mkonstan)"
>> [4], "Neale Ranns (nranns)" 
[5]
>> Cc: [6]"csit-...@lists.fd.io" [7],
>> [8]"vpp-dev@lists.fd.io" [9]
>> Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are 
we
>> there yet ? [awoken]
>>
>>  
>>
>> Klement,
>>
>> I'm in the process of modifying the base Vagrantfile/build 
scripts to
>> replace building the VPP native package and installing it in the 
VM to
>> simply running "make test" which takes much less time.  All of 
the
>> test runs that I have performed are clean builds on a virgin git 
clone
>> repo.
>>
>> That being said, I'll give the "git clean -dfX */" a try and see 
if I
>> get different results on the 2nd pass and report back.
>>
>> Thanks,
>> -daw-
>>
>> On 1/4/17 10:23 AM, Klement Sekera -X (ksekera - PANTHEON 
TECHNOLOGIES
>> at Cisco) wrote:
>>
>>   Hi Dave,
>>
>>
>>
>>   could you please try running git

Re: [vpp-dev] [csit-dev] vpp make test for verify - are we there yet ? [awoken]

2017-01-27 Thread Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)

Hi Dave,

my research says that the timestamp is inside the .pyc file and that the
modification time of the file is ignored. I tried to fool python by
having a source compiled, the changing the source file and touching the
.pyc file to see if it'll use stale bytecode, but it didn't.

Either way - if this works, then that's great. Just one comment - could
you please add a comment describing why the sleep is needed?

Thanks,
Klement

Quoting Dave Wallace (2017-01-27 03:16:25)
> Klement/Neale,
> 
> I finally got back to debugging this issue.  After doing a make 
> test-wipe, then make test.  The patched python files and their 
> corresponding .pyc files had the same timestamp with a 1-second 
> resolution.  I deleted all .pyc files and then all of the tests passed.  
> After doing some research, I confirmed that python uses a 1-second 
> resolution when checking whether to recompile the *.pyc file.
> 
> I have verified that the following patch resolves this issue both on 
> Ubuntu 16.04 in Vagrant and Ubuntu 16.10 on bare metal:
> 
> https://gerrit.fd.io/r/#/c/4896/
> 
> Thanks,
> -daw-
> 
> On 01/05/2017 03:54 AM, Klement Sekera -X (ksekera - PANTHEON 
> TECHNOLOGIES at Cisco) wrote:
> > Dave, there is no sign of test framework installing/patching scapy in
> > the log you provided.
> >
> > Could you please do in the same workspace
> >
> > make test-wipe
> >
> > and then run the make test again? I don't think it'll actually help us,
> > because there should be no way for a python inside virtualenv to get its
> > hands on outside libs (unless there is a bug of course), but let's see
> > what happens...
> >
> > Thanks,
> > Klement
> >
> > Quoting Dave Wallace (2017-01-04 19:19:04)
> >> Neale,
> >>
> >> I could not find scapy installed in the normal path (i.e. "which 
> >> scapy"),
> >> but I'm not sure if it is directly executable.  You can find the "V=1
> >> TEST=mpls make test" output on
> >> vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin 
> >> doc:
> >> [1]http://pastebin.com/uGAUREhK
> >>
> >> Thanks,
> >> -daw-
> >>
> >> On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote:
> >>
> >>
> >>
> >>   Hi,
> >>
> >>
> >>
> >>   The reason the MPLS tests are failing is because scapy cannot decode 
> >> an
> >>   MPLS label stack (output from some .show() instrumentation);
> >>
> >>
> >>
> >>   
> >>
> >>   ###[ Ethernet ]###
> >>
> >> dst   = 02:01:00:00:ff:02
> >>
> >> src   = 02:fe:e5:05:0e:13
> >>
> >> type  = 0x8847
> >>
> >>   ###[ MPLS ]###
> >>
> >>label = 33L
> >>
> >>cos   = 0L
> >>
> >>s = 0L   << NON End-of-stack
> >>
> >>ttl   = 254
> >>
> >>   ###[ Padding ]###
> >>
> >>   load  = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11
> >>   
> >> \xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257
> >>   1 1'
> >>
> >>
> >>
> >>   we patch scapy for this purpose, see;
> >>
> >> /test/patches/scapy-2.3.3/mpls.py.patch
> >>
> >>
> >>
> >>   on my vagrant 14.04 there is no other scapy installation, this patch
> >>   applies fine and all MPLS tests pass.
> >>
> >>   On a UCS 14.04, with another scapy installation:
> >>
> >> /usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py
> >>
> >>   the MPLS test fail.
> >>
> >>   On a UCS 16.04 no scpay installation, tests pass.
> >>
> >>
> >>
> >>   Do you have scapy installed in the machines on which the tests
> >>   fail/pass? Or am I barking up the wrong virtualenv tree J
> >>
> >>
> >>
> >>   Thanks,
> >>
> >>   neale
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Dave Wallace [2]
> >> Date: Wednesday, 4 January 2017 at 15:38
> >> To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
> >> [3], "Maciek Konstantynowicz (mkonstan)"
> >> [4], "Neale Ranns (nranns)" 
> >> [5]
> >> Cc: [6]"csit-...@lists.fd.io" [7],
> >> [8]"vpp-dev@lists.fd.io" [9]
> >> Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are we
> >> there yet ? [awoken]
> >>
> >>  
> >>
> >> Klement,
> >>
> >> I'm in the process of modifying the base Vagrantfile/build scripts 
> >> to
> >> replace building the VPP native package and installing it in the 
> >> VM to
> >> simply running "make test" which takes much less time.  All of the
> >> test runs that I have performed are clean builds on a virgin git 
> >> clone
> >> repo.
> >>
> >> That being said, I'll give the "git clean -dfX */" a try and see 
> >> if I
> >> get different results on the 2nd pass and report back.
> >>
> >> Thanks,
> >> -daw-
> >>
> >> On 1/4/17 10:23 AM, Klement Sekera -X (k

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

2017-01-27 Thread Christian Ehrhardt

On Thu, Jan 26, 2017 at 6:46 PM, Burt Silverman  wrote:

> Thanks, Christian, this is great information.
>
> Just for fun, before I read this, I wanted to test some of my kernel
> building skills. So I just wish to build modules in the drivers/vfio
> directory. I want to do what might be called "building an external module"
> or "building only one kernel module" as in http://askubuntu.com/
> questions/515407/how-recipe-to-build-only-one-kernel-module or "building
> a third party module". But the Google hits like that one assume that you
> have no interest in changing the .config.
>

Is that "Building a module with a different kernel config than the kernel"?
In that case that as so close to breaking it intentionally as possible :-)

> And one Ubuntu package that may be useful, linux-source, has info showing
> up in Synaptic saying "you don't want this package."
>

That is what you really want -
https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
Maybe we should say this in the package - yet URLs tend to change ...

> Here is my procedure and I hope it works -- it is relatively painless.
> I'll describe it for a particular level. I am using the desktop version of
> Ubuntu.
>
[...]

> This is tricky stuff because there is plenty of non-information and
> misinformation out there AND
>

IMHO it just is complex enough to confuse everybody more often than not
(myself included if I haven't done it for a few weeks/months).
I'm believing in the good of people and expect all misinformation to be
based on some case that worked for whoever wrote it in the past :-)
In that sense, yours likely will fail for many others AND even for you in a
certain time int he future.

[...]

> Well, this stuff may be slightly off topic,

Only slightly :-)

> but if I ever have to retrieve my instructions, I'll know where to search,
> chuckle.

For me the (currently) "right" way to build an external kernel module is
DKMS (https://help.ubuntu.com/community/DKMS).
For the reasons I mentioned above - intentionally not buidling with
different kernel config (never do that, if you want build the full kernel).
At a slightly higher rampup time DKMS gives you automatic rebuild of the
module on kernel update.
So you update your system and get a new security update - fine your extra
module will automatically be re-built for you and work - yeah.
That is e.g. what we do for the out-of-tree igb_uio module (to get it a bit
back to topic) - see
https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=blob;f=debian/dpdk-igb-uio-dkms.dkms;h=5141ff61221afeb0b2bb63034665780532c2a46d;hb=refs/heads/16.11.x

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Can't map NSH entry in VPP

Re: [vpp-dev] Can't map NSH entry in VPP

Re: [vpp-dev] Can't map NSH entry in VPP

Re: [vpp-dev] Can't map NSH entry in VPP

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

Re: [vpp-dev] Ping utility in VPP

Re: [vpp-dev] VPP-616 VPP Vagrant default box -> puppetlabs Ubuntu 16.04

[vpp-dev] Can't map NSH entry in VPP

Re: [vpp-dev] vpp build failure while creating rpm package

Re: [vpp-dev] vpp build failure while creating rpm package

[vpp-dev] vpp build failure while creating rpm package

Re: [vpp-dev] SNAT Plugin Use

Re: [vpp-dev] SNAT Plugin Use

Re: [vpp-dev] Ping utility in VPP

Re: [vpp-dev] [csit-dev] vpp make test for verify - are we there yet ? [awoken]

Re: [vpp-dev] [csit-dev] vpp make test for verify - are we there yet ? [awoken]

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

17 matches

Site Navigation

Mail list logo

Footer information