Re: [vpp-dev] VPP and SR-IOV(?): No packets reaching VPP interfaces

[Tomas Brännström]

*(I forgot to mention before, this is running with VPP installed from
binaries with release .stable.1701)*

With PF do you mean packet filter? I don't think we have any such
configuration. If there is anything else I should provide then please tell
:)

I decided to try to attach to the VPP process with gdb and I actually get a
crash when trying to do "ip probe":

vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
exec error: Misc

Program received signal SIGSEGV, Segmentation fault.
ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 ,
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
at
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
2223
 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:
No such file or directory.
(gdb) bt
#0  ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 ,
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
at
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223

Whether this is related or not I'm not sure because yesterday I could do
the probe but got "Resolution failed". I've attached the stack trace at any
rate.

/Tomas

On 11 May 2017 at 20:25, Damjan Marion (damarion) 
wrote:

> Dear Tomas,
>
> Can you please share your PF configuration so I can try to reproduce?
>
> Thanks,
>
> Damjan
>
> On 11 May 2017, at 17:07, Tomas Brännström 
> wrote:
>
> Hello
> Since the last mail I sent I've managed to get our test client working and
> VPP running in a KVM VM.
>
> We are still facing some problems though. We have a two servers, one where
> the virtual machines are running and one we use as the openstack
> controller. They are connected to each other with a 10G NIC. We have SR-IOV
> configured for the 10G NIC.
>
> So VPP is installed in a VM, and all interfaces work OK, then can be
> reached from outside the VM etc. Following the basic examples on the wiki,
> we configure VPP to take over the interfaces:
>
> vpp# set int ip address TenGigabitEthernet0/6/0 10.0.1.101/24
> vpp# set int ip address TenGigabitEthernet0/7/0 10.0.2.101/24
> vpp# set int state TenGigabitEthernet0/6/0 up
> vpp# set int state TenGigabitEthernet0/7/0 up
>
> But when trying to ping for example the physical NIC on the other server,
> we get no reply:
>
> vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
> ip probe-neighbor: Resolution failed for 10.0.1.1
>
> If I do a tcpdump on the physical interface when trying to ping, I see ARP
> packets being sent so -something- is happening, but it seems that packets
> are not correctly arriving to VPP... I can't ping from the physical host
> either, but the ARP cache is updated on the host when trying to ping from
> VPP.
>
> I've tried dumping counters etc. but I can't really see anything. The
> trace does not show anything either. This is the output from "show
> hardware":
>
> vpp# show hardware
>   NameIdx   Link  Hardware
> TenGigabitEthernet0/6/01 up   TenGigabitEthernet0/6/0
>   Ethernet address fa:16:3e:04:42:d1
>   Intel 82599 VF
> carrier up full duplex speed 1 mtu 9216
> rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
> tx frames ok   3
> tx bytes ok  126
> extended stats:
>   tx good packets  3
>   tx good bytes  126
> TenGigabitEthernet0/7/02 up   TenGigabitEthernet0/7/0
>   Ethernet address fa:16:3e:f2:15:a5
>   Intel 82599 VF
> carrier up full duplex speed 1 mtu 9216
> rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
> I've tried a similar setup between two virtual box VM's and that worked
> OK, so I'm thinking it might have something to do with SR-IOV for some
> reason. I'm having a hard time troubleshooting this since I'm not sure how
> to check where the packets actually get lost...
>
> /Tomas
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
Program received signal SIGSEGV, Segmentation fault.
ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 , 
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
2223
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:
 No such file or directory.
(gdb) bt
#0  ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 , 
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
#1  0x7f6814c60aab in ip4_probe_neighbor_wait (retry_count=3, 
sw_if_index=1, a=0x7f67d345cc50, vm=0x7f681533e720 )
at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/lookup.c:848
#2  probe_neighbor_address (vm=0x7f681533e720 , 
inp

[vpp-dev] Fwd: Dropping ubuntu 14.04 from from all verify/merge jobs for ALL releases past/current/future

[Ed Kern (ejk)]

forwarding to the correct vpp-dev list

Begin forwarded message:

From: "Ed Kern (ejk)" mailto:e...@cisco.com>>
Subject: Dropping ubuntu 14.04 from from all verify/merge jobs for ALL releases 
past/current/future
Date: May 11, 2017 at 11:12:34 AM MDT
To: "vpp-dev(mailer list)" mailto:vpp-...@cisco.com>>, 
"Damjan Marion (damarion)" mailto:damar...@cisco.com>>
Cc: Dave Barach mailto:dbar...@cisco.com>>, murali 
Venkateshaiah mailto:mura...@cisco.com>>, John Lo 
mailto:l...@cisco.com>>


TLDR   A request has been made to no longer build VPP ubuntu 14.04 verify or 
merge jobs for all releases.  Please speak
up if you object to this happening by CoB 5/15.



Hi folks,


An original request to remove ubuntu 14.04 from master (and > 17.04) from 
damjan more than a month ago was brought
to my attention to actually make happen.  During discussion in the TSC dbarach 
made a comment/change that he didn’t feel
any of the older builds  (1606, 1609, 1701, 1704) needed automatic builds for 
14.04 either at this point.
So this expanded the request (into the much easier jjb change) to just put all 
of ubuntu 14.04 into the trashcan.
I was asked to send email to this list and to the individuals above to make 
sure there were no objections.
If folks think this change should be communicated elsewhere feel free to 
forward.
If folks think I should allow more than 2 business days for someone to raise 
objection please let me know.

Damjan: Folks on the TSC call also requested that you communicate this 
(possible) change to any downstream consumer
of those builds to make sure this won’t cause explosions downstream.


thanks,

Ed

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

[vpp-dev] Fwd: Dropping ubuntu 14.04 from from all verify/merge jobs for ALL releases past/current/future

[Ed Kern (ejk)]

forwarding to the correct vpp-dev list

Begin forwarded message:

From: "Ed Kern (ejk)" mailto:e...@cisco.com>>
Subject: Dropping ubuntu 14.04 from from all verify/merge jobs for ALL releases 
past/current/future
Date: May 11, 2017 at 11:12:34 AM MDT
To: "vpp-dev(mailer list)" mailto:vpp-...@cisco.com>>, 
"Damjan Marion (damarion)" mailto:damar...@cisco.com>>
Cc: Dave Barach mailto:dbar...@cisco.com>>, murali 
Venkateshaiah mailto:mura...@cisco.com>>, John Lo 
mailto:l...@cisco.com>>


TLDR   A request has been made to no longer build VPP ubuntu 14.04 verify or 
merge jobs for all releases.  Please speak
up if you object to this happening by CoB 5/15.



Hi folks,


An original request to remove ubuntu 14.04 from master (and > 17.04) from 
damjan more than a month ago was brought
to my attention to actually make happen.  During discussion in the TSC dbarach 
made a comment/change that he didn’t feel
any of the older builds  (1606, 1609, 1701, 1704) needed automatic builds for 
14.04 either at this point.
So this expanded the request (into the much easier jjb change) to just put all 
of ubuntu 14.04 into the trashcan.
I was asked to send email to this list and to the individuals above to make 
sure there were no objections.
If folks think this change should be communicated elsewhere feel free to 
forward.
If folks think I should allow more than 2 business days for someone to raise 
objection please let me know.

Damjan: Folks on the TSC call also requested that you communicate this 
(possible) change to any downstream consumer
of those builds to make sure this won’t cause explosions downstream.


thanks,

Ed

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

[vpp-dev] DPDK forwarding through line

[Pragash Vijayaragavan]

Hi,

We are trying to sent traffic through the line from one DUT to another, we
created the traffic using moongen, but we are not aware of how to forward
the traffic to the line using dpdk, since our destination ips cant change.

Is there any way through which we can send traffic through the line from 1
DUT to another

Can someone point us to any documentation which can be helpful for this.

Topology :
|   DPDK eth1 |
|   moongen||
DPDK eth1 |
--- |   (DUT 1)  | -- |
 (DUT 2) |
|||
   |


Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu
ph : 585 764 4662
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP and SR-IOV(?): No packets reaching VPP interfaces

[Damjan Marion (damarion)]

Dear Tomas,

Can you please share your PF configuration so I can try to reproduce?

Thanks,

Damjan

On 11 May 2017, at 17:07, Tomas Brännström 
mailto:tomas.a.brannst...@tieto.com>> wrote:

Hello
Since the last mail I sent I've managed to get our test client working and VPP 
running in a KVM VM.

We are still facing some problems though. We have a two servers, one where the 
virtual machines are running and one we use as the openstack controller. They 
are connected to each other with a 10G NIC. We have SR-IOV configured for the 
10G NIC.

So VPP is installed in a VM, and all interfaces work OK, then can be reached 
from outside the VM etc. Following the basic examples on the wiki, we configure 
VPP to take over the interfaces:

vpp# set int ip address TenGigabitEthernet0/6/0 
10.0.1.101/24
vpp# set int ip address TenGigabitEthernet0/7/0 
10.0.2.101/24
vpp# set int state TenGigabitEthernet0/6/0 up
vpp# set int state TenGigabitEthernet0/7/0 up

But when trying to ping for example the physical NIC on the other server, we 
get no reply:

vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
ip probe-neighbor: Resolution failed for 10.0.1.1

If I do a tcpdump on the physical interface when trying to ping, I see ARP 
packets being sent so -something- is happening, but it seems that packets are 
not correctly arriving to VPP... I can't ping from the physical host either, 
but the ARP cache is updated on the host when trying to ping from VPP.

I've tried dumping counters etc. but I can't really see anything. The trace 
does not show anything either. This is the output from "show hardware":

vpp# show hardware
  NameIdx   Link  Hardware
TenGigabitEthernet0/6/01 up   TenGigabitEthernet0/6/0
  Ethernet address fa:16:3e:04:42:d1
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

tx frames ok   3
tx bytes ok  126
extended stats:
  tx good packets  3
  tx good bytes  126
TenGigabitEthernet0/7/02 up   TenGigabitEthernet0/7/0
  Ethernet address fa:16:3e:f2:15:a5
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

I've tried a similar setup between two virtual box VM's and that worked OK, so 
I'm thinking it might have something to do with SR-IOV for some reason. I'm 
having a hard time troubleshooting this since I'm not sure how to check where 
the packets actually get lost...

/Tomas

___
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] C++ app for processing udp messages

[Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco)]

Hi,

I have FD.IO setup to receive a multicast stream. I would like to create a c++ 
app to process the udp messages but I am having trouble figuring out what api 
to use and how to set this up.

The messages I am trying to processes are as follows:

00:14:50:997590: dpdk-input
  GigabitEthernet6/0/3 rx queue 0
  buffer 0xddcbf8: current data 14, length 1428, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x9
  PKT MBUF: port 2, nb_segs 1, pkt_len 1442
buf_len 2176, data_len 1442, ol_flags 0x180, data_off 128, phys_addr 
0x932bd00
packet_type 0x211
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
  RTE_PTYPE_L4_UDP (0x0200) UDP packet
  IP4: 00:02:c5:1b:51:07 -> 01:00:5e:00:00:01
  UDP: 10.10.10.33 -> 232.0.0.1
tos 0x00, ttl 64, length 1428, checksum 0x392d
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1000 -> 5001
length 1408, checksum 0x
00:14:50:997591: ip4-input-no-checksum
  UDP: 10.10.10.33 -> 232.0.0.1
tos 0x00, ttl 64, length 1428, checksum 0x392d
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1000 -> 5001
length 1408, checksum 0x
00:14:50:997592: ip4-mfib-forward-lookup
  fib 0 entry 6
00:14:50:997592: ip4-mfib-forward-rpf
  entry 6 3 Accept,

Which API should I use to accomplish this?

Thanks,

Guy


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

Re: [vpp-dev] VPP and SR-IOV(?): No packets reaching VPP interfaces

[Tomas Brännström]

It's a very good query but yes that works :)

/T

On 11 May 2017 at 17:21, Ernst, Eric  wrote:

> Perhaps a silly query, but can you verify connectivity between the two
> hosts with SRIO-V without VPP in the VM?
>
> Eric
>
> On May 11, 2017, at 8:07 AM, Tomas Brännström <
> tomas.a.brannst...@tieto.com> wrote:
>
> Hello
> Since the last mail I sent I've managed to get our test client working and
> VPP running in a KVM VM.
>
> We are still facing some problems though. We have a two servers, one where
> the virtual machines are running and one we use as the openstack
> controller. They are connected to each other with a 10G NIC. We have SR-IOV
> configured for the 10G NIC.
>
> So VPP is installed in a VM, and all interfaces work OK, then can be
> reached from outside the VM etc. Following the basic examples on the wiki,
> we configure VPP to take over the interfaces:
>
> vpp# set int ip address TenGigabitEthernet0/6/0 10.0.1.101/24
> vpp# set int ip address TenGigabitEthernet0/7/0 10.0.2.101/24
> vpp# set int state TenGigabitEthernet0/6/0 up
> vpp# set int state TenGigabitEthernet0/7/0 up
>
> But when trying to ping for example the physical NIC on the other server,
> we get no reply:
>
> vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
> ip probe-neighbor: Resolution failed for 10.0.1.1
>
> If I do a tcpdump on the physical interface when trying to ping, I see ARP
> packets being sent so -something- is happening, but it seems that packets
> are not correctly arriving to VPP... I can't ping from the physical host
> either, but the ARP cache is updated on the host when trying to ping from
> VPP.
>
> I've tried dumping counters etc. but I can't really see anything. The
> trace does not show anything either. This is the output from "show
> hardware":
>
> vpp# show hardware
>   NameIdx   Link  Hardware
> TenGigabitEthernet0/6/01 up   TenGigabitEthernet0/6/0
>   Ethernet address fa:16:3e:04:42:d1
>   Intel 82599 VF
> carrier up full duplex speed 1 mtu 9216
> rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
> tx frames ok   3
> tx bytes ok  126
> extended stats:
>   tx good packets  3
>   tx good bytes  126
> TenGigabitEthernet0/7/02 up   TenGigabitEthernet0/7/0
>   Ethernet address fa:16:3e:f2:15:a5
>   Intel 82599 VF
> carrier up full duplex speed 1 mtu 9216
> rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
> I've tried a similar setup between two virtual box VM's and that worked
> OK, so I'm thinking it might have something to do with SR-IOV for some
> reason. I'm having a hard time troubleshooting this since I'm not sure how
> to check where the packets actually get lost...
>
> /Tomas
>
> ___
> 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 and SR-IOV(?): No packets reaching VPP interfaces

[Ernst, Eric]

Perhaps a silly query, but can you verify connectivity between the two hosts 
with SRIO-V without VPP in the VM?

Eric

On May 11, 2017, at 8:07 AM, Tomas Brännström 
mailto:tomas.a.brannst...@tieto.com>> wrote:

Hello
Since the last mail I sent I've managed to get our test client working and VPP 
running in a KVM VM.

We are still facing some problems though. We have a two servers, one where the 
virtual machines are running and one we use as the openstack controller. They 
are connected to each other with a 10G NIC. We have SR-IOV configured for the 
10G NIC.

So VPP is installed in a VM, and all interfaces work OK, then can be reached 
from outside the VM etc. Following the basic examples on the wiki, we configure 
VPP to take over the interfaces:

vpp# set int ip address TenGigabitEthernet0/6/0 
10.0.1.101/24
vpp# set int ip address TenGigabitEthernet0/7/0 
10.0.2.101/24
vpp# set int state TenGigabitEthernet0/6/0 up
vpp# set int state TenGigabitEthernet0/7/0 up

But when trying to ping for example the physical NIC on the other server, we 
get no reply:

vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
ip probe-neighbor: Resolution failed for 10.0.1.1

If I do a tcpdump on the physical interface when trying to ping, I see ARP 
packets being sent so -something- is happening, but it seems that packets are 
not correctly arriving to VPP... I can't ping from the physical host either, 
but the ARP cache is updated on the host when trying to ping from VPP.

I've tried dumping counters etc. but I can't really see anything. The trace 
does not show anything either. This is the output from "show hardware":

vpp# show hardware
  NameIdx   Link  Hardware
TenGigabitEthernet0/6/01 up   TenGigabitEthernet0/6/0
  Ethernet address fa:16:3e:04:42:d1
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

tx frames ok   3
tx bytes ok  126
extended stats:
  tx good packets  3
  tx good bytes  126
TenGigabitEthernet0/7/02 up   TenGigabitEthernet0/7/0
  Ethernet address fa:16:3e:f2:15:a5
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

I've tried a similar setup between two virtual box VM's and that worked OK, so 
I'm thinking it might have something to do with SR-IOV for some reason. I'm 
having a hard time troubleshooting this since I'm not sure how to check where 
the packets actually get lost...

/Tomas

___
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] VPP and SR-IOV(?): No packets reaching VPP interfaces

[Tomas Brännström]

Hello
Since the last mail I sent I've managed to get our test client working and
VPP running in a KVM VM.

We are still facing some problems though. We have a two servers, one where
the virtual machines are running and one we use as the openstack
controller. They are connected to each other with a 10G NIC. We have SR-IOV
configured for the 10G NIC.

So VPP is installed in a VM, and all interfaces work OK, then can be
reached from outside the VM etc. Following the basic examples on the wiki,
we configure VPP to take over the interfaces:

vpp# set int ip address TenGigabitEthernet0/6/0 10.0.1.101/24
vpp# set int ip address TenGigabitEthernet0/7/0 10.0.2.101/24
vpp# set int state TenGigabitEthernet0/6/0 up
vpp# set int state TenGigabitEthernet0/7/0 up

But when trying to ping for example the physical NIC on the other server,
we get no reply:

vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
ip probe-neighbor: Resolution failed for 10.0.1.1

If I do a tcpdump on the physical interface when trying to ping, I see ARP
packets being sent so -something- is happening, but it seems that packets
are not correctly arriving to VPP... I can't ping from the physical host
either, but the ARP cache is updated on the host when trying to ping from
VPP.

I've tried dumping counters etc. but I can't really see anything. The trace
does not show anything either. This is the output from "show hardware":

vpp# show hardware
  NameIdx   Link  Hardware
TenGigabitEthernet0/6/01 up   TenGigabitEthernet0/6/0
  Ethernet address fa:16:3e:04:42:d1
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

tx frames ok   3
tx bytes ok  126
extended stats:
  tx good packets  3
  tx good bytes  126
TenGigabitEthernet0/7/02 up   TenGigabitEthernet0/7/0
  Ethernet address fa:16:3e:f2:15:a5
  Intel 82599 VF
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024

I've tried a similar setup between two virtual box VM's and that worked OK,
so I'm thinking it might have something to do with SR-IOV for some reason.
I'm having a hard time troubleshooting this since I'm not sure how to check
where the packets actually get lost...

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

[vpp-dev] Fwd: [dpdk-dev] [dpdk-announce] DPDK 17.05 released

[Damjan Marion (damarion)]

And we have DPDK 17.05 as default in VPP (merged 15 min ago).

Thanks,

Damjan


Begin forwarded message:

From: Thomas Monjalon mailto:tho...@monjalon.net>>
Subject: [dpdk-dev] [dpdk-announce] DPDK 17.05 released
Date: 11 May 2017 at 04:39:53 GMT+2
To: annou...@dpdk.org

A new major release is available:
http://fast.dpdk.org/rel/dpdk-17.05.tar.xz

It is the biggest release ever!
1263 patches from 128 authors
1218 files changed, 121233 insertions(+), 32610 deletions(-)

There are 60 new contributors
(including authors, reviewers and testers):
Thanks to Alex Marginean, Alexey Kardashevskiy, Allain Legacy, Ami Sabo,
Andriy Berestovskyy, Billy McFall, Charles Myers, Chris Metcalf,
Cristian Sovaiala, David Riddoch, David Su, Derek Chickles, Ed Czeck,
Fangfang Wei, Gage Eads, Gang Jiang, Gang Yang, Geoff Thorpe,
Gregory Etelson, Guduri Prathyusha, Henry Cai, Herakliusz Lipiec,
Hiroki Shirokura, Horia Geanta Neag, Huanle Han, Ivan Nardi,
Jens Freimann, Jin Heo, Johan Samuelsson, John Jacques, John Miller,
Joseph Richard, Julien Castets, Laura Stroe, Laurent Hardy, Lijuan A Tu,
Mallesham Jatharakonda, Marcin Wilk, Marcin Wojtas, Mark Asselstine,
Mark Bloch, Matt Peters, Michal Krawczyk, Nirmoy Das, Pankaj Gupta,
Pawel Rutkowski, Roman Korynkevych, Roman Zhukov, Roy Pledge,
Sagar Abhang, Shepard Siegel, Shijith Thotton, Shrikrishna Khare,
Shyam Kumar Shrivastav, Srisivasubramanian S, Sunil Kulkarni,
Timothy Redaelli, Venkat Koppula, Vipin Varghese, Wei Wang.

These new contributors are associated with these domain names:
6wind.com, atomicrules.com, brocade.com, caviumnetworks.com,
ericsson.com, huawei.com, intel.com, ustc.edu.cn, mellanox.com,
nxp.com, oktetlabs.ru, oneconvergence.com, ozlabs.ru, radware.com,
redhat.com, scaleway.com, semihalf.com, solarflare.com, spirent.com,
suse.de, vmware.com, weka.io, windriver.com.

Some highlights:
- PCI and VDEV bus rework in progress
- mbuf rework
- event driven programming model
- software eventdev driver
- Cavium OCTEON TX eventdev driver
- Cavium LiquidIO driver
- NXP DPAA2 drivers
- Atomic Rules Arkville driver
- Wind River AVP driver
- DOCSIS BPI+ crypto

More details in the release notes:
http://dpdk.org/doc/guides/rel_notes/release_17_05.html

The new features for the 17.08 cycle must be submitted before the end
of May, in order to be reviewed and integrated during June.
The next release is expected to happen at the very beginning of August.

There were a lot of bugs discovered in the last days of 17.05.
It is probably a sign that DPDK is more and more tested.
If you want to dedicate a machine for DPDK testing
and automatically send/publish the reports,
please join the CI team on c...@dpdk.org:
http://dpdk.org/ml/listinfo/ci

Thanks everyone
DPDK: where collaboration meets networking

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

Re: [vpp-dev] dpdk_device_input - not checking for vlan header...

[John Lo (loj)]

The patch for dpdk-input node to use etype is:
https://gerrit.fd.io/r/#/c/5563/

It is in 1704 or newer VPP and would match with your observation.

Regards,
John

From: Nagaprabhanjan Bellaru [mailto:nagp.li...@gmail.com]
Sent: Thursday, May 11, 2017 7:39 AM
To: John Lo (loj) 
Cc: Damjan Marion (damarion) ; vpp-dev 
Subject: Re: [vpp-dev] dpdk_device_input - not checking for vlan header...

I am using VPP having tag "v17.01.1". I still see the problem, debugging is 
on...
Thanks,
-nagp

On Tue, May 9, 2017 at 7:06 PM, John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Any chance you are using an older version of VPP, like 1609 or earlier? I kind 
of remember earlier version of VPP having this issue because it was relying on 
the packet type provided by DPDK driver and some NIC/driver did not provide 
packet type information consistently. In order to avoid this problem, we 
implemented dpdk_next_from_etype(), as mentioned by Damjan, in 
src/plugin/dpdk/device/node.c which rely on the etype of the packet only.
-John

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Nagaprabhanjan Bellaru
Sent: Tuesday, May 09, 2017 5:49 AM
To: Damjan Marion (damarion) mailto:damar...@cisco.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] dpdk_device_input - not checking for vlan header...

 Ok, let me check again, the reason I don't suspect the packet is because, if I 
disable DPDK optimization (directly feed to ip4-no-checksum) - the packets are 
getting processed fine without any issues.
Thanks,
-nagp

On Tue, May 9, 2017 at 3:09 PM, Damjan Marion (damarion) 
mailto:damar...@cisco.com>> wrote:
dpdk_rx_next_from_etype () will return value different than 
VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT _only_ if ethertype is
ETHERNET_TYPE_IP4, ETHERNET_TYPE_IP6 or ETHERNET_TYPE_MPLS.

So looks like ethertype in your packet is set to one of three listed above, 
which is wrong.

On 9 May 2017, at 10:27, Nagaprabhanjan Bellaru 
mailto:nagp.li...@gmail.com>> wrote:

Yes, it is set correctly. To validate it, I bypassed the dpdk optimization and 
fed every packet to ethernet-input (by making "dpdk_rx_next_from_etype" always 
return VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT). Then things started working fine 
- packets getting classified to correct sw_if_index, ip header pointing to 
beginning of ip header etc.
I am referring to the way l3_offset is set by looking up 
device_input_next_node_advance[next] - there is no check to skip the vlan 
header - can you please point me to the code snippet in dpdk_device_input which 
does that? "vnet_feature_start_device_input" does not seem to be doing anything 
here..
Thanks,
-nagp

On Mon, May 8, 2017 at 7:32 PM, Damjan Marion (damarion) 
mailto:damar...@cisco.com>> wrote:
>
> On 3 May 2017, at 13:28, Nagaprabhanjan Bellaru 
> mailto:nagp.li...@gmail.com>> wrote:
>
> Hi,
>
> It looks like dpdk_device_input() - is not checking if there is a vlan header 
> in the packet or not and always sets the buffer->current_data to 14 
> (smac+dmac+ethtype). Because of that ip4_input is not able to recognize a 
> correct IP packet.
>
> For example, I have a subinterface created with vlan100 - which is trying to 
> send IP packets. The receiving side is setting l3offset to 14 and feeding the 
> packet to ip4-input-no-checksum and is getting dropped there.
>
> Am I missing something? "show interface" shows the main and the sub 
> interface. "show trace" for dpdk_input shows the vlan tag as 100. But 
> ip4_input_inline gets a buffer with current_data as 14 instead of 18 
> (accounting for vlan header)

We do respect VLAN ethertypes, is your ethertype set correctly?




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

Re: [vpp-dev] unix-epoll-input consuming 100% CPU

[Nagaprabhanjan Bellaru]

Thanks a lot Damjan, can you please point me to the commit so that I can
pick them?

Thanks,
-nagp

On Tue, May 9, 2017 at 7:02 PM, Damjan Marion 
wrote:

>
>
> On 9 May 2017, at 10:30, Nagaprabhanjan Bellaru 
> wrote:
>
> Hi,
>
> I am running vpp lite version with no nodes in the polling mode, but still
> unix-epoll-input goes to polling mode and vpp_main consumes 100% CPU.
>
> Please find the "show run" output here:
> https://pastebin.com/0STv9JQV
>
> When I stepped through the unix-epoll-input code - timeout_ms calculations
> always cause it to become zero and hence epoll_[p]wait comes out as soon as
> it gets in. How can we explain this behavior?
>
>
> This issue is fixed in latest master...
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] dpdk_device_input - not checking for vlan header...

[Nagaprabhanjan Bellaru]

I am using VPP having tag "v17.01.1". I still see the problem, debugging is
on...

Thanks,
-nagp

On Tue, May 9, 2017 at 7:06 PM, John Lo (loj)  wrote:

> Any chance you are using an older version of VPP, like 1609 or earlier? I
> kind of remember earlier version of VPP having this issue because it was
> relying on the packet type provided by DPDK driver and some NIC/driver did
> not provide packet type information consistently. In order to avoid this
> problem, we implemented dpdk_next_from_etype(), as mentioned by Damjan, in
> src/plugin/dpdk/device/node.c which rely on the etype of the packet only.
>   -John
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Nagaprabhanjan Bellaru
> *Sent:* Tuesday, May 09, 2017 5:49 AM
> *To:* Damjan Marion (damarion) 
> *Cc:* vpp-dev 
> *Subject:* Re: [vpp-dev] dpdk_device_input - not checking for vlan
> header...
>
>
>
>  Ok, let me check again, the reason I don't suspect the packet is because,
> if I disable DPDK optimization (directly feed to ip4-no-checksum) - the
> packets are getting processed fine without any issues.
>
> Thanks,
>
> -nagp
>
>
>
> On Tue, May 9, 2017 at 3:09 PM, Damjan Marion (damarion) <
> damar...@cisco.com> wrote:
>
> dpdk_rx_next_from_etype () will return value different
> than VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT _only_ if ethertype is
>
> ETHERNET_TYPE_IP4, ETHERNET_TYPE_IP6 or ETHERNET_TYPE_MPLS.
>
>
>
> So looks like ethertype in your packet is set to one of three listed
> above, which is wrong.
>
>
>
> On 9 May 2017, at 10:27, Nagaprabhanjan Bellaru 
> wrote:
>
>
>
> Yes, it is set correctly. To validate it, I bypassed the dpdk optimization
> and fed every packet to ethernet-input (by making "dpdk_rx_next_from_etype"
> always return VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT). Then things started
> working fine - packets getting classified to correct sw_if_index, ip header
> pointing to beginning of ip header etc.
>
> I am referring to the way l3_offset is set by looking up
> device_input_next_node_advance[next] - there is no check to skip the vlan
> header - can you please point me to the code snippet in dpdk_device_input
> which does that? "vnet_feature_start_device_input" does not seem to be
> doing anything here..
>
> Thanks,
>
> -nagp
>
>
>
> On Mon, May 8, 2017 at 7:32 PM, Damjan Marion (damarion) <
> damar...@cisco.com> wrote:
>
> >
> > On 3 May 2017, at 13:28, Nagaprabhanjan Bellaru 
> wrote:
> >
> > Hi,
> >
> > It looks like dpdk_device_input() - is not checking if there is a vlan
> header in the packet or not and always sets the buffer->current_data to 14
> (smac+dmac+ethtype). Because of that ip4_input is not able to recognize a
> correct IP packet.
> >
> > For example, I have a subinterface created with vlan100 - which is
> trying to send IP packets. The receiving side is setting l3offset to 14 and
> feeding the packet to ip4-input-no-checksum and is getting dropped there.
> >
> > Am I missing something? "show interface" shows the main and the sub
> interface. "show trace" for dpdk_input shows the vlan tag as 100. But
> ip4_input_inline gets a buffer with current_data as 14 instead of 18
> (accounting for vlan header)
>
> We do respect VLAN ethertypes, is your ethertype set correctly?
>
>
>
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Question: make realclean

[Thomas F Herbert]

On 05/08/2017 10:11 AM, Damjan Marion (damarion) wrote:


On 3 May 2017, at 17:20, Jon Loeliger > wrote:


Hey VPP Builders,

Do you ever use "cd build-root; make distclean"?
Does it look sort of like this:


jdl $ cd build-root/
jdl $ make distclean
rm -rf /home/jdl/workspace/vpp/build-root/build-*/
rm -rf /home/jdl/workspace/vpp/build-root/build-tool-*
rm -rf /home/jdl/workspace/vpp/build-root/install-*
rm -rf /home/jdl/workspace/vpp/build-root/images-*
rm -rf /home/jdl/workspace/vpp/build-root/tools
rm -rf /home/jdl/workspace/vpp/build-root/*.deb
rm -rf /home/jdl/workspace/vpp/build-root/*.rpm
rm -rf /home/jdl/workspace/vpp/build-root/*.changes
rm -rf /home/jdl/workspace/vpp/build-root/python
if [ -e /usr/bin/dh ];then (cd 
/home/jdl/workspace/vpp/build-root/deb/;debian/rules clean); fi

rm -f /home/jdl/workspace/vpp/build-root/deb/debian/*.install
rm -f /home/jdl/workspace/vpp/build-root/deb/debian/changelog

Remember back in

commit c06eeb0e3c9c1a9fa8f913e2d785b03220bfdabd
Author: Damjan Marion mailto:damar...@cisco.com>>
Date:   Tue Apr 18 15:26:39 2017 +0200

Fix "make dist" to include version number, docouple it from rpm 
packaging


Change-Id: If2f9976d668089026c97b897cf449bff09050631
Signed-off-by: Damjan Marion >


when we moved the RPM building pieces out of build-root/rpm and
placed them under extras/rpm instead?

Should we have also modified the distclean make target to rm the rpms
out of extras/rpm too?  Or was that an intentional change as well?


Makes sense to do that from top level makefile, i.e. run "git clean 
-fdX” but

I would prefer that build-root/Makefile only takes care for build-root/.

+1



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


--
*Thomas F Herbert*
Fast Data Planes
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev