[vpp-dev] Tap IF Names

2017-03-23 Thread Jon Loeliger 
Guys,

Why do tap interfaces use the name "tap-%d" internally?  The user has
given an actual name (that corresponds to the underlying Linux tap name),
and yet VPP makes up a non-correlatable different name in the form "tap-%d"
by making up some number and assigning it to the IF.

This issue is precisely the same problem that loopback IF names had,
and for which I submitted a patch to at least allow deterministically
predictable
IF names for user-assigned names on loopbacks.

Later, there is some form of ability to "renumber" tap interfaces.  Will
this
affect the numbering of the IF names the user sees?

Specifically, I'm wondering if we can somehow unify the tap name prefix
with the other interface prefixing styles in a more standard, cohesive and
predictable way.  In the case of tap IFs, having VPP instead at least use
the name "tap-%s", formatted with the user-supplied name would make
it predictable and somewhat similar to the other IF types.

I *think* this table summarizes the current state of IF names for many
of the interface types.

Thanks,
jdl



DPDK:
User says : TenGigabitEthernet6/0/0
VPP uses  : TenGigabitEthernet6/0/0
Linux uses: 

Loopback:
User says :  - for "create" and "delete" commands
VPP uses  : loop - for any other reference to the IF
Linux : 

Host AF_PACKET
User says :  - for "create" and "delete" commands
VPP uses  : host- - for any other reference to the IF
Linux uses: 
Note: Leftover(?) use of "veth" in all VPP Wiki pages still?

Tap:
User says :  - for "create" and "delete" commands
VPP uses  : tap- - for any other reference to the IF
Linux uses: 
Note: No relationship between  and 

netmap:
User says :  - for "create" and "delete" commands
VPP uses  : netmap- - for any other reference to the IF
Linux uses: 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp-plugins RPM dependency

2017-03-23 Thread Thomas F Herbert 



On 03/22/2017 04:36 PM, Feng Pan wrote:
So this would suggest that VPP by default (that is, by doing 'yum 
install vpp') will not have dpdk support, and vpp-plugins must also be 
installed to add it, I would think dpdk plugin should be either 
packaged or installed together with VPP by default, and can be 
disabled if desired.


In any case, will deployment model stay this way? I'll need to make 
changes to puppet module to include other packages if that's how it 
will be going forward. Also, dpdk section should be commented out in 
the config file so we can start VPP service using the default config.
The dpdk plugin build process  precipitated major headaches working for 
downstream packaging for Centos as well. I had a patch ready to submit 
for building from a dist tarball as a step toward building from a source 
rpm but that can't be used now.  The main problem is vpp can no longer 
build from a isolated tarball without git. Installing the development 
rpm as part of downstream installation is not an option either. The 
build process does not support dependency on an external rpm yet such as 
that which is built in rpm_dpdk project. I am thinking out load here but 
the best option for achieving packaging for 17.04 is to build dpdk from 
the tarball, bypass the dpdk rpm and include the upstream dpdk tarball 
in the srpm. Hopefully we can get a better solution figured out by next 
release over 17.0x that will work with the dpdk plugin concept.


Thanks
Feng

On Wed, Mar 22, 2017 at 2:46 PM, Ed Warnicke > wrote:


Commenting out the dpdk stanza is a great workaround but we may
want to look at bit more closely at the issue... as installing the
vpp project should result in an out of the box runnable vpp.

Ed

On Wed, Mar 22, 2017 at 11:44 AM, Dave Barach (dbarach)
mailto:dbar...@cisco.com>> wrote:

Simply remove the “dpdk” stanza from /etc/vpp/startup.conf if
you want to run vpp without the dpdk plugin.

Thanks… Dave

*From:*vpp-dev-boun...@lists.fd.io

[mailto:vpp-dev-boun...@lists.fd.io
] *On Behalf Of *Feng Pan
*Sent:* Wednesday, March 22, 2017 1:47 PM
*To:* vpp-dev mailto:vpp-dev@lists.fd.io>>
*Subject:* [vpp-dev] vpp-plugins RPM dependency

Hi All,

With latest master builds of VPP (on Centos with rpm repo), it
seems like it's necessary to install vpp-plugins package for
vpp to start, without it, I get the following error when
running vpp (with default config file):

vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins

vlib_call_all_config_functions: unknown input `dpdk  '

Looking at the spec file, vpp package depends on vpp-lib only,
so it appears that we need to add vpp-plugins to the
dependency list too. However, it also looks like vpp-plugins
depends on vpp package, so I'm trying to figure out what the
right dependency relationship is :)

Thanks

Feng


___
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


--
*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] VXLAN multithreading issue

2017-03-23 Thread Damjan Marion (damarion) 

I think I know where it might be a problem.
let me come back to you….

On 23 Mar 2017, at 13:08, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) mailto:pmi...@cisco.com>> wrote:

Hello vpp-dev,

With latest VPP build packages I am observing the issue with VXLAN and LISPGPE 
tunnels during my testing (CSIT and internal Cisco lab - manual testing). I am 
getting the following errors:

vpp# sh err
   CountNode  Reason
10 ip4-udp-lookup no listener for dst port
10 ip4-icmp-error destination unreachable 
response sent
10  vxlan4-encap  good packets encapsulated
10l2-output   L2 output packets
10l2-learnL2 learn packets
10l2-learnL2 learn hits
10l2-inputL2 input packets
10l2-floodL2 flood packets


Encapsulation of traffic into VXLAN is working properly but decapsulation is 
throwing "no listener for dst port"

vpp# sh trace

--- Start of thread 0 vpp_main ---
No packets in trace buffer
--- Start of thread 1 vpp_wk_0 ---
Packet 1

00:04:49:119217: dpdk-input
  FortyGigabitEtherneta/0/0 rx queue 0
  buffer 0x1d288a28: current data 14, length 94, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 108
buf_len 2176, data_len 108, ol_flags 0x180, data_off 128, phys_addr 
0x55264900
packet_type 0x291
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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers
  RTE_PTYPE_L4_UDP (0x0200) UDP packet
  IP4: 00:00:71:51:52:d7 -> 3c:fd:fe:9d:1a:a0
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119239: ip4-input-no-checksum
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119249: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119253: ip4-local
UDP: 11.0.0.2 -> 11.0.0.1
  tos 0x00, ttl 64, length 94, checksum 0x648d
  fragment id 0x
UDP: 4789 -> 4789
  length 74, checksum 0x9c98
00:04:49:119256: ip4-udp-lookup
  UDP: src-port 4789 dst-port 4789 (no listener)
00:04:49:119261: ip4-icmp-error
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119265: ip4-lookup
  fib 0 dpo-idx 2 flow hash: 0x
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 255, length 122, checksum 0xa580
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119265: ip4-rewrite
  tx_sw_if_index 1 dpo-idx 2 : ipv4 via 11.0.0.2 FortyGigabitEtherneta/0/0: 
IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7 flow hash: 0x
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119266: FortyGigabitEtherneta/0/0-output
  FortyGigabitEtherneta/0/0
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119268: FortyGigabitEtherneta/0/0-tx
  FortyGigabitEtherneta/0/0 tx queue 1
  buffer 0x1d288a28: current data -28, length 136, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b

--- Start of thread 2 vpp_wk_1 ---
Packet 1

00:04:49:119215: dpdk-input
  FortyGigabitEtherneta/0/1 rx queue 0
  buffer 0x1d292712: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x554d8380
packet_type 0x691
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

[vpp-dev] VXLAN multithreading issue

2017-03-23 Thread Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Hello vpp-dev,

With latest VPP build packages I am observing the issue with VXLAN and LISPGPE 
tunnels during my testing (CSIT and internal Cisco lab - manual testing). I am 
getting the following errors:

vpp# sh err
   CountNode  Reason
10 ip4-udp-lookup no listener for dst port
10 ip4-icmp-error destination unreachable 
response sent
10  vxlan4-encap  good packets encapsulated
10l2-output   L2 output packets
10l2-learnL2 learn packets
10l2-learnL2 learn hits
10l2-inputL2 input packets
10l2-floodL2 flood packets


Encapsulation of traffic into VXLAN is working properly but decapsulation is 
throwing "no listener for dst port"

vpp# sh trace

--- Start of thread 0 vpp_main ---
No packets in trace buffer
--- Start of thread 1 vpp_wk_0 ---
Packet 1

00:04:49:119217: dpdk-input
  FortyGigabitEtherneta/0/0 rx queue 0
  buffer 0x1d288a28: current data 14, length 94, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 108
buf_len 2176, data_len 108, ol_flags 0x180, data_off 128, phys_addr 
0x55264900
packet_type 0x291
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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers
  RTE_PTYPE_L4_UDP (0x0200) UDP packet
  IP4: 00:00:71:51:52:d7 -> 3c:fd:fe:9d:1a:a0
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119239: ip4-input-no-checksum
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119249: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119253: ip4-local
UDP: 11.0.0.2 -> 11.0.0.1
  tos 0x00, ttl 64, length 94, checksum 0x648d
  fragment id 0x
UDP: 4789 -> 4789
  length 74, checksum 0x9c98
00:04:49:119256: ip4-udp-lookup
  UDP: src-port 4789 dst-port 4789 (no listener)
00:04:49:119261: ip4-icmp-error
  UDP: 11.0.0.2 -> 11.0.0.1
tos 0x00, ttl 64, length 94, checksum 0x648d
fragment id 0x
  UDP: 4789 -> 4789
length 74, checksum 0x9c98
00:04:49:119265: ip4-lookup
  fib 0 dpo-idx 2 flow hash: 0x
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 255, length 122, checksum 0xa580
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119265: ip4-rewrite
  tx_sw_if_index 1 dpo-idx 2 : ipv4 via 11.0.0.2 FortyGigabitEtherneta/0/0: 
IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7 flow hash: 0x
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119266: FortyGigabitEtherneta/0/0-output
  FortyGigabitEtherneta/0/0
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b
00:04:49:119268: FortyGigabitEtherneta/0/0-tx
  FortyGigabitEtherneta/0/0 tx queue 1
  buffer 0x1d288a28: current data -28, length 136, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  IP4: 3c:fd:fe:9d:1a:a0 -> 00:00:71:51:52:d7
  ICMP: 11.0.0.1 -> 11.0.0.2
tos 0x00, ttl 254, length 122, checksum 0xa680
fragment id 0x
  ICMP destination_unreachable port_unreachable checksum 0x135b

--- Start of thread 2 vpp_wk_1 ---
Packet 1

00:04:49:119215: dpdk-input
  FortyGigabitEtherneta/0/1 rx queue 0
  buffer 0x1d292712: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x554d8380
packet_type 0x691
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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers
  RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet
  IP4: 00:00:22:22:00:00 -> 00