date:20200615

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

2020-06-15 Thread Manoj Iyer

Steve,

Oh wow! I enabled the ping plugin, ( it was ping_plugin.so without the 's') and 
restarted VPP, and I was able to ping from one machine to the VPP interface of 
the other! Thanks a million!

== System A with VPP interface ==
$ sudo vppctl show interface address
bnxt0 (up):
  L3 10.1.1.10/24
bnxt1 (dn):
bnxt2 (dn):
bnxt3 (dn):
local0 (dn):

$ sudo vppctl show error
   CountNode  Reason
 5   dpdk-input   no error
 1arp-reply   ARP replies sent
16llc-input   unknown llc ssap/dsap
 1ip4-glean   ARP requests sent
 9 ip4-icmp-input echo replies sent
 3   dpdk-input   no error

$ sudo vppctl show interface address
bnxt0 (up):
  L3 10.1.1.10/24
bnxt1 (dn):
bnxt2 (dn):
bnxt3 (dn):
local0 (dn):

== System B with non-vpp interface ==

$ sudo ifconfig enp2s0f1np1 10.1.1.11 netmask 255.255.255.0 up
$ ping -c4 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.
64 bytes from 10.1.1.10: icmp_seq=1 ttl=64 time=0.171 ms
64 bytes from 10.1.1.10: icmp_seq=2 ttl=64 time=0.097 ms
64 bytes from 10.1.1.10: icmp_seq=3 ttl=64 time=0.089 ms
64 bytes from 10.1.1.10: icmp_seq=4 ttl=64 time=0.091 ms

--- 10.1.1.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3078ms
rtt min/avg/max/mdev = 0.089/0.112/0.171/0.034 ms


From: Steven Luong (sluong) 
Sent: Monday, June 15, 2020 2:01 PM
To: Manoj Iyer ; Dave Barach (dbarach) ; 
vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.


Evidently, you have selectively enabled certain plugins. You should add this to 
your plugins section in your startup.conf in order to initiate ping from VPP.



plugins {

 plugin ping_plugins.so { enable }

}



Nevertheless, I don’t see icmp or arp packets come to VPP in the trace when you 
ping from the remote. What do you see in show error?

Since you enable worker threads, the first ping packet from the remote always 
fails. Don’t give up so easily. Try pinging second time after it fails.



Steven



From:  on behalf of Manoj Iyer 
Date: Monday, June 15, 2020 at 9:42 AM
To: "Steven Luong (sluong)" , "Dave Barach (dbarach)" 
, "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.



Steven,



vppctl does not have a ping command I am on version 20.5 (may be I did not 
compile this option?) Also not sure how to parse this trace output.



When I ping System B from System A and run the trace on SystemB I get the 
following output:



$ sudo vppctl show trace

--- Start of thread 0 vpp_main ---

No packets in trace buffer

--- Start of thread 1 vpp_wk_0 ---

Packet 1



00:06:46:741025: dpdk-input

  bnxt0 rx queue 0

  buffer 0x56cb7: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100

  ext-hdr-valid

  l4-cksum-computed l4-cksum-correct

  PKT MBUF: port 0, nb_segs 1, pkt_len 119

buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f65c80

packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

Packet Types

  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00

00:06:46:741035: ethernet-input

  frame: flags 0x3, hw-if-index 1, sw-if-index 1

  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00

00:06:46:741038: llc-input

  LLC bpdu -> bpdu

00:06:46:741042: error-drop

  rx:bnxt0

00:06:46:741043: drop

  llc-input: unknown llc ssap/dsap



Packet 2



00:06:48:741182: dpdk-input

  bnxt0 rx queue 0

  buffer 0x56ca2: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x101

  ext-hdr-valid

  l4-cksum-computed l4-cksum-correct

  PKT MBUF: port 0, nb_segs 1, pkt_len 119

buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f65200

packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

Packet Types

  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00

00:06:48:741185: ethernet-input

  frame: flags 0x3, hw-if-index 1, sw-if-index 1

  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00

00:06:48:741186: llc-input

  LLC bpdu -> bpdu

00:06:48:741186: error-drop

  rx:bnxt0

00:06:48:741187: drop

  llc-input: unknown llc ssap/dsap



Packet 3



00:06:50:741453: dpdk-input

  bnxt0 rx queue 0

  buffer 0x56c8d: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x102

  ext-hdr-valid

  l4-cksum-computed l4-cksum-correct

  PKT MBUF: port 0, nb_segs

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

2020-06-15 Thread Amit Mehra

Hi Manoj,

You need to enable ping_plugin.so and then you would be able to see the
ping CLI command

On Mon, 15 Jun, 2020, 10:11 pm Manoj Iyer,  wrote:

> Steven,
>
> vppctl does not have a ping command I am on version 20.5 (may be I did not
> compile this option?) Also not sure how to parse this trace output.
>
> When I ping System B from System A and run the trace on SystemB I get the
> following output:
>
> $ sudo vppctl show trace
> --- Start of thread 0 vpp_main ---
> No packets in trace buffer
> --- Start of thread 1 vpp_wk_0 ---
> Packet 1
>
> 00:06:46:741025: dpdk-input
>   bnxt0 rx queue 0
>   buffer 0x56cb7: current data 0, length 119, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x100
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 119
> buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr
> 0x70f65c80
> packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:46:741035: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:46:741038: llc-input
>   LLC bpdu -> bpdu
> 00:06:46:741042: error-drop
>   rx:bnxt0
> 00:06:46:741043: drop
>   llc-input: unknown llc ssap/dsap
>
> Packet 2
>
> 00:06:48:741182: dpdk-input
>   bnxt0 rx queue 0
>   buffer 0x56ca2: current data 0, length 119, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x101
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 119
> buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr
> 0x70f65200
> packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:48:741185: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:48:741186: llc-input
>   LLC bpdu -> bpdu
> 00:06:48:741186: error-drop
>   rx:bnxt0
> 00:06:48:741187: drop
>   llc-input: unknown llc ssap/dsap
>
> Packet 3
>
> 00:06:50:741453: dpdk-input
>   bnxt0 rx queue 0
>   buffer 0x56c8d: current data 0, length 119, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x102
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 119
> buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr
> 0x70f64780
> packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:50:741455: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:50:741456: llc-input
>   LLC bpdu -> bpdu
> 00:06:50:741457: error-drop
>   rx:bnxt0
> 00:06:50:741457: drop
>   llc-input: unknown llc ssap/dsap
>
> Packet 4
>
> 00:06:52:741564: dpdk-input
>   bnxt0 rx queue 0
>   buffer 0x56c78: current data 0, length 119, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x103
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 119
> buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr
> 0x70f63d00
> packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:52:741567: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
> 00:06:52:741568: llc-input
>   LLC bpdu -> bpdu
> 00:06:52:741568: error-drop
>   rx:bnxt0
> 00:06:52:741569: drop
>   llc-input: unknown llc ssap/dsap
>
> Packet 5
>
> 00:06:54:474773: dpdk-input
>   bnxt0 rx queue 0
>   buffer 0x56c63: current data 0, length 319, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x104
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 319
> buf_len 2176, data_len 319, ol_flags 0x182, data_off 128, phys_addr
> 0x70f63280
> packet_type 0x291 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x8ae4b80f fdir.hi 0x0 fdir.lo 0x8ae4b80f
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

2020-06-15 Thread Manoj Iyer

Steven,

vppctl does not have a ping command I am on version 20.5 (may be I did not 
compile this option?) Also not sure how to parse this trace output.

When I ping System B from System A and run the trace on SystemB I get the 
following output:

$ sudo vppctl show trace
--- Start of thread 0 vpp_main ---
No packets in trace buffer
--- Start of thread 1 vpp_wk_0 ---
Packet 1

00:06:46:741025: dpdk-input
  bnxt0 rx queue 0
  buffer 0x56cb7: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 119
buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f65c80
packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:46:741035: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:46:741038: llc-input
  LLC bpdu -> bpdu
00:06:46:741042: error-drop
  rx:bnxt0
00:06:46:741043: drop
  llc-input: unknown llc ssap/dsap

Packet 2

00:06:48:741182: dpdk-input
  bnxt0 rx queue 0
  buffer 0x56ca2: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x101
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 119
buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f65200
packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:48:741185: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:48:741186: llc-input
  LLC bpdu -> bpdu
00:06:48:741186: error-drop
  rx:bnxt0
00:06:48:741187: drop
  llc-input: unknown llc ssap/dsap

Packet 3

00:06:50:741453: dpdk-input
  bnxt0 rx queue 0
  buffer 0x56c8d: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x102
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 119
buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f64780
packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:50:741455: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:50:741456: llc-input
  LLC bpdu -> bpdu
00:06:50:741457: error-drop
  rx:bnxt0
00:06:50:741457: drop
  llc-input: unknown llc ssap/dsap

Packet 4

00:06:52:741564: dpdk-input
  bnxt0 rx queue 0
  buffer 0x56c78: current data 0, length 119, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x103
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 119
buf_len 2176, data_len 119, ol_flags 0x0, data_off 128, phys_addr 0x70f63d00
packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:52:741567: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  0x0069: 18:e8:29:21:03:13 -> 01:80:c2:00:00:00
00:06:52:741568: llc-input
  LLC bpdu -> bpdu
00:06:52:741568: error-drop
  rx:bnxt0
00:06:52:741569: drop
  llc-input: unknown llc ssap/dsap

Packet 5

00:06:54:474773: dpdk-input
  bnxt0 rx queue 0
  buffer 0x56c63: current data 0, length 319, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x104
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 319
buf_len 2176, data_len 319, ol_flags 0x182, data_off 128, phys_addr 
0x70f63280
packet_type 0x291 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x8ae4b80f fdir.hi 0x0 fdir.lo 0x8ae4b80f
Packet Offload Flags
  PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
  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: 18:e8:29:21:03:12 -> ff:ff:ff:ff:ff:ff
  UDP: 0.0.0.0 -> 255.255.255.255
tos 0x10, ttl 64, length 305, checksum 0x79ad dscp unknown ecn NON_ECN

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

2020-06-15 Thread steven luong via lists.fd.io

Manoj,

Because system B is running VPP, you can’t initiate the ping from system B in 
Unix Shell. Kernel does not have that interface and IP address anymore for you 
to do the ping. You have to start the ping from vppctl if you want to do the 
ping from system B running VPP.

When you do the ping from system A, type
vppctl show error
vppctl show interface
may help you to find out why the packet got dropped or if it arrives at all to 
VPP. If that still does not help, take the trace from VPP. Something like this

vppctl trace add dpdk-input 100
ping 10.1.1.10  <-- ping rom system A
vppctl show trace

Honestly, I’ve never worked with a Broadcom NIC which you are using.
tx burst function: bnxt_xmit_pkts
rx burst function: bnxt_recv_pkts
May the force be with you.

Steven

From: Manoj Iyer 
Date: Monday, June 15, 2020 at 7:48 AM
To: "Dave Barach (dbarach)" , "Steven Luong (sluong)" 
, "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Dave/Steven,

I set the netmask on both sides to 255.255.255.0 and here is how I setup the ip 
address on the 2 servers. System-B has ip address set using vppctl and system-A 
was setup using ifconfig, as below. The link is up on both enp2s0f1np1 on 
System A and bnxt0 on System B. VPP version used is 20.05.

Also on System B where I setup 10.1.1.10 as the IP address on the VPP interface 
bnxt0, I was not able to ping that IP from the host system (System B). Please 
see below towards the end where this ping fails.

(Also, I setup the exact same physical interfaces without using VPP and was 
able to ping each other.)

== System A ==
$ sudo ifconfig enp2s0f1np1 10.1.1.11 netmask 255.255.255.0 up
$ ifconfig enp2s0f1np1
enp2s0f1np1: flags=4163  mtu 1500
inet 10.1.1.11  netmask 255.255.255.0  broadcast 10.1.1.255
ether b0:26:28:82:09:cd  txqueuelen 1000  (Ethernet)
RX packets 635  bytes 183934 (183.9 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 150  bytes 20610 (20.6 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ ethtool enp2s0f1np1
Settings for enp2s0f1np1:
Supported ports: [ FIBRE ]
Supported link modes:   1baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  1baseT/Full
   25000baseCR/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x (0)

Link detected: yes

== System B (vppctl for ip setup ) ==
$ sudo vppctl set int ip address bnxt0 10.1.1.10/24
$ sudo vppctl show interface address
bnxt0 (up):
  L3 10.1.1.10/24
bnxt1 (dn):
bnxt2 (dn):
bnxt3 (dn):
local0 (dn):
$ sudo vppctl show hardware
  NameIdx   Link  Hardware
bnxt0  1 up   bnxt0
  Link speed: 10 Gbps
  Ethernet address 00:10:18:ad:05:00
  Broadcom NetXtreme E/S-Series
carrier up full duplex mtu 9206
flags: admin-up pmd tx-offload rx-ip4-cksum
Devargs:
rx: queues 3 (max 73), desc 512 (min 16 max 8192 align 1)
tx: queues 4 (max 73), desc 512 (min 16 max 4096 align 1)
pci: device 14e4:d804 subsystem 14e4:8040 address 0008:01:00.00 numa 0
max rx packet len: 9600
promiscuous: unicast off all-multicast on
vlan offload: strip on filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   outer-ipv4-cksum vlan-filter vlan-extend jumbo-frame
   scatter timestamp keep-crc rss-hash
rx offload active: vlan-strip ipv4-cksum
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso
   outer-ipv4-cksum qinq-insert vxlan-tnl-tso gre-tnl-tso
   ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso
   outer-ipv4-cksum vxlan-tnl-tso gre-tnl-tso ipip-tnl-tso
   geneve-tnl-tso multi-segs
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp ipv6-udp ipv6
rss active:ipv4-tcp ipv4-udp ipv4 ipv6-tcp ipv6-udp ipv6
tx burst function: bnxt_xmit_pkts
rx burst function: bnxt_recv_pkts

== Ping System A from System B ==
$ ping -c1 10.1.1.11
PING 10.1.1.11 (10.1.1.11) 56(84) bytes of data.

--- 10.1.1.11 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

== Ping System B from System A ==
$ ping -c1 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.
From 10.1.1.11 icmp_seq=1 Destination Host Unreachable

--- 10.1.1.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

== Ping System A interface from System A ==
$ ping -c1

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

2020-06-15 Thread Matthew Smith

HI Amit,

Here's a patch which I think will fix the problem:
https://gerrit.fd.io/r/c/vpp/+/27563. If you are able to build with the
patch applied and test it, that would be very helpful.

Thanks,
-Matt



On Sun, Jun 14, 2020 at 12:51 AM Amit Mehra  wrote:

> Thanks Muthu Raj for the Response.
>
> When i am setting "accept_mode" to NO while configuring VRRP router on VPP
> instance-2 (refer my configurations for VPP inst1 and inst 2 in initial
> mail) and when i kill VPP instance-1, then VRRP router running on VPP
> instance-2 is becoming the Master (IP 10.20.37.118 is not added to vpp
> interface this time, as accept_mode was NO) but when i am trying to ping
> 10.20.37.118 from external machine(having same subnet as 10.20.37.xx) then
> ping is not successful. I tried capturing the trace on vpp interface, as is
> being as shown as packets getting dropped.
>
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>state Master flags: preempt yes accept no unicast no
>priority: configured 200 adjusted 200
>timers: adv interval 100 master adv 100 skew 21 master down 321
>virtual MAC 00:00:5e:00:01:01
>addresses 10.20.37.118
>peer addresses
>tracked interfaces
>
> vpp# show int addr
> GigabitEthernet13/0/0 (up):
>   L3 10.20.37.109/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> vpp# show trace
> 00:03:38:573635: dpdk-input
>   GigabitEthernet13/0/0 rx queue 1
>   buffer 0x1e3492: current data 0, length 98, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle
> 0x102
>ext-hdr-valid
>l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 98
> buf_len 2176, data_len 98, ol_flags 0x82, data_off 128, phys_addr
> 0x88cd2500
> packet_type 0x91 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0xe0a3989 fdir.hi 0x0 fdir.lo 0xe0a3989
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP 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
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573648: ethernet-input
>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
> 00:03:38:573653: ip4-input
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573656: ip4-lookup
>   fib 0 dpo-idx 0 flow hash: 0x
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573659: ip4-glean
> ICMP: 10.20.37.21 -> 10.20.37.118
>   tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>   fragment id 0x7b52, flags DONT_FRAGMENT
> ICMP echo_request checksum 0xdf6e
> 00:03:38:573664: ip4-drop
> ICMP: 10.20.37.21 -> 10.20.37.118
>   tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>   fragment id 0x7b52, flags DONT_FRAGMENT
> ICMP echo_request checksum 0xdf6e
> 00:03:38:573675: error-drop
>   rx:GigabitEthernet13/0/0
> 00:03:38:573676: drop
>   ip4-glean: ARP requests sent
>
> Moreover, as per RFC-5798(https://tools.ietf.org/html/rfc5798), sec 6.1
> 
>
> Accept_ModeControls whether a virtual router in
>Master state will accept packets
>addressed to the address owner's IPvX
>address as its own if it is not the IPvX
>address owner.  The default is False.
>Deployments that rely on, for example,
>pinging the address owner's IPvX address
>may wish to configure Accept_Mode to
>True.
>
> And also sec 6.4.3, when VRRP router acting as Master
> (650) - MUST accept packets addressed to the IPvX address(es)
>   associated with the virtual router if it is the IPvX address owner
>   or if Accept_Mode is True.  Otherwise, MUST NOT accept these
>   packets.
>
> So, as per my understanding I need to set "accept_mode" to YES as per my
> use-case. My usecase is that IP 10.20.37.118 should always be pingable from
> outside machine (having same subnet as 10.20.37.118)
>
> Please let me know if my understanding is correct or whether I am missing
> anything in my configuration?
>
> Regards
> Amit
> 
>

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

2020-06-15 Thread Manoj Iyer

Dave/Steven,

I set the netmask on both sides to 255.255.255.0 and here is how I setup the ip 
address on the 2 servers. System-B has ip address set using vppctl and system-A 
was setup using ifconfig, as below. The link is up on both enp2s0f1np1 on 
System A and bnxt0 on System B. VPP version used is 20.05.

Also on System B where I setup 10.1.1.10 as the IP address on the VPP interface 
bnxt0, I was not able to ping that IP from the host system (System B). Please 
see below towards the end where this ping fails.

(Also, I setup the exact same physical interfaces without using VPP and was 
able to ping each other.)

== System A ==
$ sudo ifconfig enp2s0f1np1 10.1.1.11 netmask 255.255.255.0 up
$ ifconfig enp2s0f1np1
enp2s0f1np1: flags=4163  mtu 1500
inet 10.1.1.11  netmask 255.255.255.0  broadcast 10.1.1.255
ether b0:26:28:82:09:cd  txqueuelen 1000  (Ethernet)
RX packets 635  bytes 183934 (183.9 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 150  bytes 20610 (20.6 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ ethtool enp2s0f1np1
Settings for enp2s0f1np1:
Supported ports: [ FIBRE ]
Supported link modes:   1baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  1baseT/Full
   25000baseCR/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x (0)

Link detected: yes

== System B (vppctl for ip setup ) ==
$ sudo vppctl set int ip address bnxt0 10.1.1.10/24
$ sudo vppctl show interface address
bnxt0 (up):
  L3 10.1.1.10/24
bnxt1 (dn):
bnxt2 (dn):
bnxt3 (dn):
local0 (dn):
$ sudo vppctl show hardware
  NameIdx   Link  Hardware
bnxt0  1 up   bnxt0
  Link speed: 10 Gbps
  Ethernet address 00:10:18:ad:05:00
  Broadcom NetXtreme E/S-Series
carrier up full duplex mtu 9206
flags: admin-up pmd tx-offload rx-ip4-cksum
Devargs:
rx: queues 3 (max 73), desc 512 (min 16 max 8192 align 1)
tx: queues 4 (max 73), desc 512 (min 16 max 4096 align 1)
pci: device 14e4:d804 subsystem 14e4:8040 address 0008:01:00.00 numa 0
max rx packet len: 9600
promiscuous: unicast off all-multicast on
vlan offload: strip on filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   outer-ipv4-cksum vlan-filter vlan-extend jumbo-frame
   scatter timestamp keep-crc rss-hash
rx offload active: vlan-strip ipv4-cksum
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso
   outer-ipv4-cksum qinq-insert vxlan-tnl-tso gre-tnl-tso
   ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso
   outer-ipv4-cksum vxlan-tnl-tso gre-tnl-tso ipip-tnl-tso
   geneve-tnl-tso multi-segs
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp ipv6-udp ipv6
rss active:ipv4-tcp ipv4-udp ipv4 ipv6-tcp ipv6-udp ipv6
tx burst function: bnxt_xmit_pkts
rx burst function: bnxt_recv_pkts

== Ping System A from System B ==
$ ping -c1 10.1.1.11
PING 10.1.1.11 (10.1.1.11) 56(84) bytes of data.

--- 10.1.1.11 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

== Ping System B from System A ==
$ ping -c1 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.
>From 10.1.1.11 icmp_seq=1 Destination Host Unreachable

--- 10.1.1.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

== Ping System A interface from System A ==
$ ping -c1 10.1.1.11
PING 10.1.1.11 (10.1.1.11) 56(84) bytes of data.
64 bytes from 10.1.1.11: icmp_seq=1 ttl=64 time=0.033 ms

--- 10.1.1.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms

== Ping System B interface from System B ==
$ ping -c1 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.

--- 10.1.1.10 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Thanks
Manoj Iyer

From: Dave Barach (dbarach) 
Sent: Friday, June 12, 2020 3:21 PM
To: Steven Luong (sluong) ; Manoj Iyer ; 
vpp-dev@lists.fd.io 
Subject: RE: [vpp-dev] Need help with setup.. cannot ping a VPP interface.


+check hardware addresses with “show hardware”, to make sure you’ve configured 
the interface which is actually connected to the peer system / switch...



HTH... Dave



From: vpp-dev@lists.fd.io  On Behalf Of steven luong via 
lists.fd.io
Sent: Friday, June 12, 2020 4:18

Re: [vpp-dev] Regarding vlib_time_now

2020-06-15 Thread Prashant Upadhyaya

Thanks Dave.
Yes I have taken care of that in my code. I always use the highest
value seen as the ceiling in the logic of my code. If I see a lower
value I use the ceiling else move on and record the new ceiling.
Earlier math counted on an increasing value, so bad things were
happening in my code, looks ok now.

Regards
-Prashant

On Mon, Jun 15, 2020 at 7:07 PM Dave Barach (dbarach)  wrote:
>
> That's within reason given that thread time offsets are not recalculated 
> immediately, and that (for stability reasons) the clock-rate update algorithm 
> uses exponential smoothing.
>
> Aside from accounting for the issue in your code, there probably isn't much 
> to be done about it...
>
> D
>
> -Original Message-
> From: Prashant Upadhyaya 
> Sent: Monday, June 15, 2020 8:58 AM
> To: Dave Barach (dbarach) 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Regarding vlib_time_now
>
> Hi Dave,
>
> Thanks, on a VM I am observing the reduction from a couple of microseconds to 
> 50 microseconds at times NTP was turned on. After turning it off, I don't see 
> the time reduction.
> The output of the command is below
>
> vppctl show clock verbose
>
> Time now 16712.719968, reftime 16712.719967, error .01, clocks/sec
> 2596982853.770165
>
> Time last barrier release 16709.938950671
>
> 1: Time now 16710.417730, reftime 16710.417730, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279669 error -.00032
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16715.621101, reftime 16715.621101, error 0.00, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16712.721636492
>
> 1: Time now 16713.318854, reftime 16713.318854, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279482 error -.8
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16718.249427, reftime 16718.249427, error 0.00, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16715.621212275
>
> 1: Time now 16715.947179, reftime 16715.947179, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279562 error -.8
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16719.646461, reftime 16719.646461, error 0.00, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16718.249525477
>
> 1: Time now 16717.344206, reftime 16717.344206, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279598 error -.9
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16721.162232, reftime 16721.162232, error 0.00, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16720.702629716
>
> 1: Time now 16718.859979, reftime 16718.859979, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279598 error -.8
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16722.313997, reftime 16722.313997, error 0.00, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16721.162470894
>
> 1: Time now 16720.011753, reftime 16720.011753, error 0.00, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279597 error -.9
>
> Regards
> -Prashant
>
> On Sun, Jun 14, 2020 at 8:12 PM Dave Barach (dbarach)  
> wrote:
> >
> > What is the magnitude of the delta that you observe? What does "show clock 
> > verbose" say about the state of clock-rate convergence? Is a deus ex 
> > machina (e.g. NTP) involved?
> >
> >
> >
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Prashant
> > Upadhyaya
> > Sent: Sunday, June 14, 2020 10:32 AM
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Regarding vlib_time_now
> >
> >
> >
> > Hi,
> >
> >
> >
> > I am using VPP 19.08
> >
> > In my worker threads, I am observing that when I am making successive calls 
> > to vlib_time_now in a polling node, sometimes the value of the time reduces.
> >
> > Is this expected to happen ? (presumably because of the implementation 
> > which tries to align the times in workers ?) I have an implementation which 
> > is extremely sensitive to time at microsecond level and depends on the the 
> > vlib_time_now only increasing monotonically across calls individually in 
> > the workers (or remain the same but never decrease) on a per worker basis 
> > even if the times within the workers are not synchronized.
> >
> >
> >
> > Regards
> >
> > -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16730): https://lists.fd.io/g/vpp-dev/message/16730
Mute This Topic: https://lists.fd.io/mt/74875583/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe:

[vpp-dev] Fetching SR Policy data using VPP C API

2020-06-15 Thread Chinmaya Aggarwal

Hi,
We have added sr policies in VPP using VPP C API. We now want to fetch these 
policy data similar to what we get in "show sr policies", using VPP C API. How 
can we fetch this data using VPP C API so that the segment list indices are 
similar to those in "show sr policies" command?
Below is a sample output of "show sr policies" : -

vpp# show sr policies
SR policies:
[0].-   BSID: c1::999:3
Behavior: SRH insertion
Type: Default
FIB table: 0
Segment Lists:
[0].- < 2001:19:a1::1, 2001:19:a2::1 > weight: 9
[1].- < 2001:19:a3::1, 2001:19:a4::1 > weight: 9
---
[1].-   BSID: c1::999:2
Behavior: SRH insertion
Type: Default
FIB table: 0
Segment Lists:
[2].- < 2001:19:b1::1, 2001:19:b2::1 > weight: 9
[3].- < 2001:19:b3::1, 2001:19:b4::1 > weight: 9
[4].- < 2001:19:b5::1, 2001:19:b6::1 > weight: 9
---

We want to get segment list indices 0,1,2,3 and 4 in VPP C API policy data as 
well.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16729): https://lists.fd.io/g/vpp-dev/message/16729
Mute This Topic: https://lists.fd.io/mt/74894689/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Regarding vlib_time_now

2020-06-15 Thread Dave Barach via lists.fd.io

That's within reason given that thread time offsets are not recalculated 
immediately, and that (for stability reasons) the clock-rate update algorithm 
uses exponential smoothing.

Aside from accounting for the issue in your code, there probably isn't much to 
be done about it...

D

-Original Message-
From: Prashant Upadhyaya  
Sent: Monday, June 15, 2020 8:58 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding vlib_time_now

Hi Dave,

Thanks, on a VM I am observing the reduction from a couple of microseconds to 
50 microseconds at times NTP was turned on. After turning it off, I don't see 
the time reduction.
The output of the command is below

vppctl show clock verbose

Time now 16712.719968, reftime 16712.719967, error .01, clocks/sec
2596982853.770165

Time last barrier release 16709.938950671

1: Time now 16710.417730, reftime 16710.417730, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279669 error -.00032

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose

Time now 16715.621101, reftime 16715.621101, error 0.00, clocks/sec 
2596982853.770165

Time last barrier release 16712.721636492

1: Time now 16713.318854, reftime 16713.318854, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279482 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose

Time now 16718.249427, reftime 16718.249427, error 0.00, clocks/sec 
2596982853.770165

Time last barrier release 16715.621212275

1: Time now 16715.947179, reftime 16715.947179, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279562 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose

Time now 16719.646461, reftime 16719.646461, error 0.00, clocks/sec 
2596982853.770165

Time last barrier release 16718.249525477

1: Time now 16717.344206, reftime 16717.344206, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279598 error -.9

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose

Time now 16721.162232, reftime 16721.162232, error 0.00, clocks/sec 
2596982853.770165

Time last barrier release 16720.702629716

1: Time now 16718.859979, reftime 16718.859979, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279598 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose

Time now 16722.313997, reftime 16722.313997, error 0.00, clocks/sec 
2596982853.770165

Time last barrier release 16721.162470894

1: Time now 16720.011753, reftime 16720.011753, error 0.00, clocks/sec 
2596982875.038256

Thread 1 offset 2.302279597 error -.9

Regards
-Prashant

On Sun, Jun 14, 2020 at 8:12 PM Dave Barach (dbarach)  wrote:
>
> What is the magnitude of the delta that you observe? What does "show clock 
> verbose" say about the state of clock-rate convergence? Is a deus ex machina 
> (e.g. NTP) involved?
>
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Sunday, June 14, 2020 10:32 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding vlib_time_now
>
>
>
> Hi,
>
>
>
> I am using VPP 19.08
>
> In my worker threads, I am observing that when I am making successive calls 
> to vlib_time_now in a polling node, sometimes the value of the time reduces.
>
> Is this expected to happen ? (presumably because of the implementation which 
> tries to align the times in workers ?) I have an implementation which is 
> extremely sensitive to time at microsecond level and depends on the the 
> vlib_time_now only increasing monotonically across calls individually in the 
> workers (or remain the same but never decrease) on a per worker basis even if 
> the times within the workers are not synchronized.
>
>
>
> Regards
>
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16728): https://lists.fd.io/g/vpp-dev/message/16728
Mute This Topic: https://lists.fd.io/mt/74875583/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Regarding vlib_time_now

2020-06-15 Thread Prashant Upadhyaya

Hi Dave,

Thanks, on a VM I am observing the reduction from a couple of
microseconds to 50 microseconds at times
NTP was turned on. After turning it off, I don't see the time reduction.
The output of the command is below

vppctl show clock verbose

Time now 16712.719968, reftime 16712.719967, error .01, clocks/sec
2596982853.770165

Time last barrier release 16709.938950671

1: Time now 16710.417730, reftime 16710.417730, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279669 error -.00032

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock
verbose

Time now 16715.621101, reftime 16715.621101, error 0.00,
clocks/sec 2596982853.770165

Time last barrier release 16712.721636492

1: Time now 16713.318854, reftime 16713.318854, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279482 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock
verbose

Time now 16718.249427, reftime 16718.249427, error 0.00,
clocks/sec 2596982853.770165

Time last barrier release 16715.621212275

1: Time now 16715.947179, reftime 16715.947179, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279562 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock
verbose

Time now 16719.646461, reftime 16719.646461, error 0.00,
clocks/sec 2596982853.770165

Time last barrier release 16718.249525477

1: Time now 16717.344206, reftime 16717.344206, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279598 error -.9

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock
verbose

Time now 16721.162232, reftime 16721.162232, error 0.00,
clocks/sec 2596982853.770165

Time last barrier release 16720.702629716

1: Time now 16718.859979, reftime 16718.859979, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279598 error -.8

[root@bfs-dl360g9-16-vm4 iptabl]#
/opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock
verbose

Time now 16722.313997, reftime 16722.313997, error 0.00,
clocks/sec 2596982853.770165

Time last barrier release 16721.162470894

1: Time now 16720.011753, reftime 16720.011753, error 0.00,
clocks/sec 2596982875.038256

Thread 1 offset 2.302279597 error -.9

Regards
-Prashant

On Sun, Jun 14, 2020 at 8:12 PM Dave Barach (dbarach)  wrote:
>
> What is the magnitude of the delta that you observe? What does "show clock 
> verbose" say about the state of clock-rate convergence? Is a deus ex machina 
> (e.g. NTP) involved?
>
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Sunday, June 14, 2020 10:32 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding vlib_time_now
>
>
>
> Hi,
>
>
>
> I am using VPP 19.08
>
> In my worker threads, I am observing that when I am making successive calls 
> to vlib_time_now in a polling node, sometimes the value of the time reduces.
>
> Is this expected to happen ? (presumably because of the implementation which 
> tries to align the times in workers ?) I have an implementation which is 
> extremely sensitive to time at microsecond level and depends on the the 
> vlib_time_now only increasing monotonically across calls individually in the 
> workers (or remain the same but never decrease) on a per worker basis even if 
> the times within the workers are not synchronized.
>
>
>
> Regards
>
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16727): https://lists.fd.io/g/vpp-dev/message/16727
Mute This Topic: https://lists.fd.io/mt/74875583/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

2020-06-15 Thread aish84

Hi Ben,

This patch seems to be already applied in VPP20.01.
int
dhcp_client_for_us (u32 bi, vlib_buffer_t * b,
ip4_header_t * ip,
udp_header_t * udp, dhcp_header_t * dhcp)
{
dhcp_client_main_t *dcm = _client_main;
*vlib_main_t *vm = dcm->vlib_main;*
dhcp_client_t *c;
uword *p;
*f64 now = vlib_time_now (dcm->vlib_main);*
u8 dhcp_message_type = 0;
dhcp_option_t *o;
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16726): https://lists.fd.io/g/vpp-dev/message/16726
Mute This Topic: https://lists.fd.io/mt/74890182/21656
Mute #vpp: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

2020-06-15 Thread Benoit Ganne (bganne) via lists.fd.io

Hi,

This should have been fixed with https://gerrit.fd.io/r/c/vpp/+/27183
It is merged in master and VPP 20.05 (but not 20.01 which is no longer 
maintained).
The best should be to upgrade to 20.05.

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of
> ais...@gmail.com
> Sent: lundi 15 juin 2020 10:03
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-
> 20.01
> 
> 
> Hi Team,
> 
> I am facing an issue when I try to set the interface to DHCP Client on
> VPP-20.01 with  worker thread enabled in the startup.conf.
> Environment Used:
> 1. Vpp 20.01 running on a Ubuntu 16.01 VM.
> 2. Two CPU cores allocated
> 
> cat /proc/cpuinfo  | grep processor
> processor: 0
> processor: 1
> 
> Startup.conf
> 
> unix {
>nodaemon
>interactive \
>cli-listen /run/vpp/cli.sock
>log /tmp/vpp.log
>full-coredump
> }
> api-trace {
>on
> }
> 
> socksvr {
>   default
> }
> 
> cpu {
> main-core 0
> corelist-workers 1
> }
> 
> dpdk {
> dev :02:01.0
> }
> 
> socksvr { socket-name /tmp/vpp-api.sock}
> 
> 
> Running VPP Debug CLI:
> 
> _____   _  ___
>  __/ __/ _ \  (_)__| | / / _ \/ _ \
>  _/ _// // / / / _ \   | |/ / ___/ ___/
>  /_/ /(_)_/\___/   |___/_/  /_/
> 
> DBGvpp# show int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> GigabitEthernet2/1/0  1 down 9000/0/0/0
> local00 down  0/0/0/0
> DBGvpp# set interface state GigabitEthernet2/1/0 up
> DBGvpp# show int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> GigabitEthernet2/1/0  1  up  9000/0/0/0
> local00 down  0/0/0/0
> DBGvpp# set dhcp client intfc GigabitEthernet2/1/0
> DBGvpp# 1: /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287
> (vlib_time_now) assertion `vm->thread_index == __os_thread_index' fails
> Aborted (core dumped)
> Makefile:547: recipe for target 'run' failed
> make: *** [run] Error 134
> 
> 
> 
> Backtrace in GDB:
> 
> 
> Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
> 0x7f467392a428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54in ../sysdeps/unix/sysv/linux/raise.c
> (gdb) bt
> #0  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x7f467392c02a in __GI_abort () at abort.c:89
> #2  0x00407555 in os_exit (code=1) at /home/aishwarya/BN/vpp-
> 20.01/src/vpp/vnet/main.c:379
> #3  0x7f46742bb919 in unix_signal_handler (signum=6,
> si=0x7f4634b7d2b0, uc=0x7f4634b7d180) at /home/aishwarya/BN/vpp-
> 20.01/src/vlib/unix/main.c:187
> #4  
> #5  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #6  0x7f467392c02a in __GI_abort () at abort.c:89
> #7  0x00407510 in os_panic () at /home/aishwarya/BN/vpp-
> 20.01/src/vpp/vnet/main.c:355
> #8  0x7f4673cf1fb2 in debugger () at /home/aishwarya/BN/vpp-
> 20.01/src/vppinfra/error.c:84
> #9  0x7f4673cf24a1 in _clib_error (how_to_die=2, function_name=0x0,
> line_number=0, fmt=0x7f46307fa9f8 "%s:%d (%s) assertion `%s' fails")
> at /home/aishwarya/BN/vpp-20.01/src/vppinfra/error.c:158
> #10 0x7f463078c575 in vlib_time_now (vm=0x7f46744f2480
> ) at /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287
> #11 0x7f463078f473 in dhcp_client_for_us (bi=635348, b=0x10026c7500,
> ip=0x10026c760e, udp=0x10026c7622, dhcp=0x10026c762a)
> at /home/aishwarya/BN/vpp-20.01/src/plugins/dhcp/client.c:282
> #12 0x7f46307b2030 in dhcp_proxy_to_client_input (vm=0x7f46348f5fc0,
> node=0x7f4634bfa2c0, from_frame=0x7f4634bda980)
> at /home/aishwarya/BN/vpp-
> 20.01/src/plugins/dhcp/dhcp4_proxy_node.c:566
> #13 0x7f467425371d in dispatch_node (vm=0x7f46348f5fc0,
> node=0x7f4634bfa2c0, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f4634bda980,
> last_time_stamp=50239219631664) at /home/aishwarya/BN/vpp-
> 20.01/src/vlib/main.c:1208
> #14 0x7f4674253ede in dispatch_pending_node (vm=0x7f46348f5fc0,
> pending_frame_index=4, last_time_stamp=50239219631664) at
> /home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1376
> #15 0x7f4674255b3c in vlib_main_or_worker_loop (vm=0x7f46348f5fc0,
> is_main=0) at /home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1833
> #16 0x7f46742563aa in vlib_worker_loop (vm=0x7f46348f5fc0) at
> /home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1940
> #17 0x7f467429459a in vlib_worker_thread_fn (arg=0x7f463595b380) at
> /home/aishwarya/BN/vpp-20.01/src/vlib/threads.c:1751
> #18 0x7f4673d12394 in clib_calljmp () at /home/aishwarya/BN/vpp-
> 20.01/src/vppinfra/longjmp.S:123
> #19

[vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

2020-06-15 Thread aish84

[Edited Message Follows]

Hi Team,

I am facing an issue when I try to set the interface to DHCP Client on 
VPP-20.01 with  worker thread enabled in the startup.conf.
Environment Used:
1. Vpp 20.01 running on a Ubuntu 16.01 VM.
2. Two CPU cores allocated

cat /proc/cpuinfo  | grep processor
processor    : 0
processor    : 1

Startup.conf

unix {
nodaemon
interactive \
cli-listen /run/vpp/cli.sock
log /tmp/vpp.log
full-coredump
}
api-trace {
on
}

socksvr {
default
}

cpu {
*main-core 0*
*corelist-workers 1*
}

dpdk {
dev :02:01.0
}

socksvr { socket-name /tmp/vpp-api.sock}


Running VPP Debug CLI:

___    _    _   _  ___
__/ __/ _ \  (_)__    | | / / _ \/ _ \
_/ _// // / / / _ \   | |/ / ___/ ___/
/_/ /(_)_/\___/   |___/_/  /_/

DBGvpp# show th
ID Name    Type    LWP Sched Policy (Priority)  lcore  
Core   Socket State
0  vpp_main    50887   other (0)    0  
0  0
1  vpp_wk_0    workers 50889   other (0)    1  
0  2

DBGvpp# show int
Name   Idx    State  MTU (L3/IP4/IP6/MPLS) Counter  
Count
GigabitEthernet2/1/0  1 down 9000/0/0/0
local0    0 down  0/0/0/0
DBGvpp# set interface state GigabitEthernet2/1/0 up
DBGvpp# show int
Name   Idx    State  MTU (L3/IP4/IP6/MPLS) Counter  
Count
GigabitEthernet2/1/0  1  up  9000/0/0/0
local0    0 down  0/0/0/0
*DBGvpp# set dhcp client intfc GigabitEthernet2/1/0*
*DBGvpp# 1: /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287 (vlib_time_now) 
assertion `vm->thread_index == __os_thread_index' fails*
*Aborted (core dumped)*
Makefile:547: recipe for target 'run' failed
make: *** [run] Error 134

Backtrace in GDB:

Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54    in ../sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f467392c02a in __GI_abort () at abort.c:89
#2  0x00407555 in os_exit (code=1) at 
/home/aishwarya/BN/vpp-20.01/src/vpp/vnet/main.c:379
#3  0x7f46742bb919 in unix_signal_handler (signum=6, si=0x7f4634b7d2b0, 
uc=0x7f4634b7d180) at /home/aishwarya/BN/vpp-20.01/src/vlib/unix/main.c:187
#4  
#5  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#6  0x7f467392c02a in __GI_abort () at abort.c:89
#7  0x00407510 in os_panic () at 
/home/aishwarya/BN/vpp-20.01/src/vpp/vnet/main.c:355
#8  0x7f4673cf1fb2 in debugger () at 
/home/aishwarya/BN/vpp-20.01/src/vppinfra/error.c:84
*#9  0x7f4673cf24a1 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7f46307fa9f8 "%s:%d (%s) assertion `%s' fails")*
*at /home/aishwarya/BN/vpp-20.01/src/vppinfra/error.c:158*
*#10 0x7f463078c575 in vlib_time_now (vm=0x7f46744f2480 ) 
at /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287*
*#11 0x7f463078f473 in dhcp_client_for_us (bi=635348, b=0x10026c7500, 
ip=0x10026c760e, udp=0x10026c7622, dhcp=0x10026c762a)*
*at /home/aishwarya/BN/vpp-20.01/src/plugins/dhcp/client.c:282*
*#12 0x7f46307b2030 in dhcp_proxy_to_client_input (vm=0x7f46348f5fc0, 
node=0x7f4634bfa2c0, from_frame=0x7f4634bda980)*
*at /home/aishwarya/BN/vpp-20.01/src/plugins/dhcp/dhcp4_proxy_node.c:566*
#13 0x7f467425371d in dispatch_node (vm=0x7f46348f5fc0, 
node=0x7f4634bfa2c0, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f4634bda980,
last_time_stamp=50239219631664) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1208
#14 0x7f4674253ede in dispatch_pending_node (vm=0x7f46348f5fc0, 
pending_frame_index=4, last_time_stamp=50239219631664) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1376
#15 0x7f4674255b3c in vlib_main_or_worker_loop (vm=0x7f46348f5fc0, 
is_main=0) at /home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1833
#16 0x7f46742563aa in vlib_worker_loop (vm=0x7f46348f5fc0) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1940
#17 0x7f467429459a in vlib_worker_thread_fn (arg=0x7f463595b380) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/threads.c:1751
#18 0x7f4673d12394 in clib_calljmp () at 
/home/aishwarya/BN/vpp-20.01/src/vppinfra/longjmp.S:123
#19 0x7f361b3fed30 in ?? ()
#20 0x7f467428ec94 in vlib_worker_thread_bootstrap_fn (arg=0x7f463595b380) 
at /home/aishwarya/BN/vpp-20.01/src/vlib/threads.c:573
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Can someone please help me understand and fix this issue?

Regards,
Aishwarya
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online

[vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

2020-06-15 Thread aish84

Hi Team,

I am facing an issue when I try to set the interface to DHCP Client on 
VPP-20.01 with  worker thread enabled in the startup.conf.
Environment Used:
1. Vpp 20.01 running on a Ubuntu 16.01 VM.
2. Two CPU cores allocated

cat /proc/cpuinfo  | grep processor
processor    : 0
processor    : 1

Startup.conf

unix {
nodaemon
interactive \
cli-listen /run/vpp/cli.sock
log /tmp/vpp.log
full-coredump
}
api-trace {
on
}

socksvr {
default
}

cpu {
*main-core 0*
*corelist-workers 1*
}

dpdk {
dev :02:01.0
}

socksvr { socket-name /tmp/vpp-api.sock}


Running VPP Debug CLI:

___    _    _   _  ___
__/ __/ _ \  (_)__    | | / / _ \/ _ \
_/ _// // / / / _ \   | |/ / ___/ ___/
/_/ /(_)_/\___/   |___/_/  /_/

DBGvpp# show int
Name   Idx    State  MTU (L3/IP4/IP6/MPLS) Counter  
Count
GigabitEthernet2/1/0  1 down 9000/0/0/0
local0    0 down  0/0/0/0
DBGvpp# set interface state GigabitEthernet2/1/0 up
DBGvpp# show int
Name   Idx    State  MTU (L3/IP4/IP6/MPLS) Counter  
Count
GigabitEthernet2/1/0  1  up  9000/0/0/0
local0    0 down  0/0/0/0
*DBGvpp# set dhcp client intfc GigabitEthernet2/1/0*
*DBGvpp# 1: /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287 (vlib_time_now) 
assertion `vm->thread_index == __os_thread_index' fails*
*Aborted (core dumped)*
Makefile:547: recipe for target 'run' failed
make: *** [run] Error 134

Backtrace in GDB:

Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54    in ../sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f467392c02a in __GI_abort () at abort.c:89
#2  0x00407555 in os_exit (code=1) at 
/home/aishwarya/BN/vpp-20.01/src/vpp/vnet/main.c:379
#3  0x7f46742bb919 in unix_signal_handler (signum=6, si=0x7f4634b7d2b0, 
uc=0x7f4634b7d180) at /home/aishwarya/BN/vpp-20.01/src/vlib/unix/main.c:187
#4  
#5  0x7f467392a428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#6  0x7f467392c02a in __GI_abort () at abort.c:89
#7  0x00407510 in os_panic () at 
/home/aishwarya/BN/vpp-20.01/src/vpp/vnet/main.c:355
#8  0x7f4673cf1fb2 in debugger () at 
/home/aishwarya/BN/vpp-20.01/src/vppinfra/error.c:84
*#9  0x7f4673cf24a1 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7f46307fa9f8 "%s:%d (%s) assertion `%s' fails")*
*at /home/aishwarya/BN/vpp-20.01/src/vppinfra/error.c:158*
*#10 0x7f463078c575 in vlib_time_now (vm=0x7f46744f2480 ) 
at /home/aishwarya/BN/vpp-20.01/src/vlib/main.h:287*
*#11 0x7f463078f473 in dhcp_client_for_us (bi=635348, b=0x10026c7500, 
ip=0x10026c760e, udp=0x10026c7622, dhcp=0x10026c762a)*
*at /home/aishwarya/BN/vpp-20.01/src/plugins/dhcp/client.c:282*
*#12 0x7f46307b2030 in dhcp_proxy_to_client_input (vm=0x7f46348f5fc0, 
node=0x7f4634bfa2c0, from_frame=0x7f4634bda980)*
*at /home/aishwarya/BN/vpp-20.01/src/plugins/dhcp/dhcp4_proxy_node.c:566*
#13 0x7f467425371d in dispatch_node (vm=0x7f46348f5fc0, 
node=0x7f4634bfa2c0, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f4634bda980,
last_time_stamp=50239219631664) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1208
#14 0x7f4674253ede in dispatch_pending_node (vm=0x7f46348f5fc0, 
pending_frame_index=4, last_time_stamp=50239219631664) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1376
#15 0x7f4674255b3c in vlib_main_or_worker_loop (vm=0x7f46348f5fc0, 
is_main=0) at /home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1833
#16 0x7f46742563aa in vlib_worker_loop (vm=0x7f46348f5fc0) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/main.c:1940
#17 0x7f467429459a in vlib_worker_thread_fn (arg=0x7f463595b380) at 
/home/aishwarya/BN/vpp-20.01/src/vlib/threads.c:1751
#18 0x7f4673d12394 in clib_calljmp () at 
/home/aishwarya/BN/vpp-20.01/src/vppinfra/longjmp.S:123
#19 0x7f361b3fed30 in ?? ()
#20 0x7f467428ec94 in vlib_worker_thread_bootstrap_fn (arg=0x7f463595b380) 
at /home/aishwarya/BN/vpp-20.01/src/vlib/threads.c:573
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Can someone please help me understand and fix this issue?

Regards,
Aishwarya
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16724): https://lists.fd.io/g/vpp-dev/message/16724
Mute This Topic: https://lists.fd.io/mt/74890182/21656
Mute #vpp: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

2020-06-15 Thread Chinmaya Aggarwal

Can anyone please help us out here?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16723): https://lists.fd.io/g/vpp-dev/message/16723
Mute This Topic: https://lists.fd.io/mt/74477804/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

Re: [vpp-dev] Need help with setup.. cannot ping a VPP interface.

Re: [vpp-dev] Regarding vlib_time_now

[vpp-dev] Fetching SR Policy data using VPP C API

Re: [vpp-dev] Regarding vlib_time_now

Re: [vpp-dev] Regarding vlib_time_now

Re: [vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

Re: [vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

[vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

[vpp-dev] Crash on setting interface as DHCP client #vpp #vpp-20.01

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

15 matches

Site Navigation

Mail list logo

Footer information