Re: [vpp-dev] SIGSEGV after calling vlib_get_frame_to_node

[Dave Barach via Lists.Fd.Io]

None of the routine names in the backtrace exist in master/latest – it’s your 
code - so it will be challenging for the community to help you.

See if you can repro the problem with a TAG=vpp_debug images (aka “make build” 
not “make build-release”). If you’re lucky, one of the numerous ASSERTs will 
catch the problem early.

vlib_get_frame_to_node(...) is not new code, it’s used all over the place, and 
it needs “help” to fail as shown below.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Hugo Garza
Sent: Tuesday, November 27, 2018 7:39 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] SIGSEGV after calling vlib_get_frame_to_node

Hi vpp-dev,

I'm seeing a crash when I enable our application with multiple works.
Nov 26 14:29:32  vnet[64035]: received signal SIGSEGV, PC 0x7f6979a12ce8, 
faulting address 0x7fa6cd0bd444
Nov 26 14:29:32  vnet[64035]: #0  0x7f6a812743d8 0x7f6a812743d8
Nov 26 14:29:32  vnet[64035]: #1  0x7f6a80bc56d0 0x7f6a80bc56d0
Nov 26 14:29:32  vnet[64035]: #2  0x7f6979a12ce8 vlib_frame_vector_args + 
0x10
Nov 26 14:29:32  vnet[64035]: #3  0x7f6979a16a2c tcpo_enqueue_to_output_i + 
0xf4
Nov 26 14:29:32  vnet[64035]: #4  0x7f6979a16b23 tcpo_enqueue_to_output + 
0x25
Nov 26 14:29:32  vnet[64035]: #5  0x7f6979a33fba send_packets + 0x7f2
Nov 26 14:29:32  vnet[64035]: #6  0x7f6979a346f8 connection_tx + 0x17e
Nov 26 14:29:32  vnet[64035]: #7  0x7f6979a34f08 tcpo_dispatch_node_fn + 
0x7fa
Nov 26 14:29:32  vnet[64035]: #8  0x7f6a81248cb6 vlib_worker_loop + 0x6a6
Nov 26 14:29:32  vnet[64035]: #9  0x7f6a8094f694 0x7f6a8094f694

Running on CentOS 7.4  with kernel 3.10.0-693.el7.x86_64
VPP
Version:  v18.10-13~g00adcce~b60
Compiled by:  root
Compile host: b0f32e97e93a
Compile date: Mon Nov 26 09:09:42 UTC 2018
Compile location: /w/workspace/vpp-merge-1810-centos7
Compiler: GCC 7.3.1 20180303 (Red Hat 7.3.1-5)
Current PID:  9612

On a Cisco server with 2 socket Intel Xeon E5-2697Av4 @ 2.60GHz and 2 Intel 
X520 NICs. T-Rex traffic generator is hooked up on the other end to provided 
data at about 5Gbps per NIC.
./t-rex-64 --astf -f astf/nginx_wget.py -c 14 -m 4 -d 3000

startup.conf
unix {
  nodaemon
  interactive
  log /opt/tcpo/logs/vpp.log
  full-coredump
  cli-no-banner
  #startup-config /opt/tcpo/conf/local.conf
  cli-listen /run/vpp/cli.sock
}
api-trace {
  on
}
heapsize 3G
cpu {
  main-core 1
  corelist-workers 2-5
}
tcpo {
runtime-config /opt/tcpo/conf/runtime.conf
session-pool-size 1024000
}
dpdk {
  dev :86:00.0 {
num-rx-queues 1
  }
  dev :86:00.1 {
num-rx-queues 1
  }
  dev :84:00.0 {
num-rx-queues 1
  }
  dev :84:00.1 {
num-rx-queues 1
  }
  num-mbufs 1024000
  socket-mem 4096,4096
}
plugin_path /usr/lib/vpp_plugins
api-segment {
  gid vpp
}

Here's the function where the SIGSEGV is happening:

static void enqueue_to_output_i(tcpo_worker_ctx_t * wrk, u32 bi, u8 flush) {

u32 *to_next, next_index;

vlib_frame_t *f;



TRACE_FUNC_VAR(bi);



next_index = tcpo_output_node.index;



/* Get frame to output node */

f = wrk->tx_frame;

if (!f) {

f = vlib_get_frame_to_node(wrk->vm, next_index);

ASSERT (clib_mem_is_heap_object (f));

wrk->tx_frame = f;

}

ASSERT (clib_mem_is_heap_object (f));



to_next = vlib_frame_vector_args(f);

to_next[f->n_vectors] = bi;

f->n_vectors += 1;



if (flush || f->n_vectors == VLIB_FRAME_SIZE) {

TRACE_FUNC_VAR2(flush, f->n_vectors);

vlib_put_frame_to_node(wrk->vm, next_index, f);

wrk->tx_frame = 0;

}

}


I've observed that after a few Gbps of traffic go through and we call 
vlib_get_frame_to_node the pointer f that gets returned points to a chunk of 
memory that is invalid as confirmed by the assert statement that I added 
afterwards right below.

Not sure how to progress further on tracking down this issue, any help or 
advice would be much appreciated.

Thanks,
Hugo
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11444): https://lists.fd.io/g/vpp-dev/message/11444
Mute This Topic: https://lists.fd.io/mt/28408842/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] About in-band telnet/ssh support of VPP

[Dave Barach via Lists.Fd.Io]

If you want/need a solution 90 seconds ago, take a look here: 
https://wiki.fd.io/view/VPP/VPP_Home_Gateway

Add a user ("admin", maybe?) whose login shell is vppctl, and you're done.

Please don't create a gigantic security hole.

D.

From: tianye@sina 
Sent: Tuesday, November 27, 2018 12:19 AM
To: 'Hu, Xuekun' ; Dave Barach (dbarach) 
; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] About in-band telnet/ssh support of VPP

Partially completed work will also be welcome if you agree to share.
Or you can just push your temporary work to sandbox gerrit so that anyone could 
get some idea about how to porting.
You never understand how we need it :)

From: Hu, Xuekun [mailto:xuekun...@intel.com]
Sent: Tuesday, November 27, 2018 12:58 PM
To: dbar...@cisco.com<mailto:dbar...@cisco.com>; tianye@sina; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] About in-band telnet/ssh support of VPP

Dave, can you estimate when the sshd work to be done? We really like this 
feature.
Thanks.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, November 26, 2018 8:42 PM
To: tianye@sina mailto:tiany...@sina.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] About in-band telnet/ssh support of VPP

Please do not use the vpp host stack to listen to port 23 (telnet) on a 
network-facing interface. You could do that, but please don't do that.

All you would need to add is a well-known default password, and you would have 
created a super-trivial attack surface for your product.

Florin and I are working to crank up sshd over the host stack. No guaranteed 
end-date, but it's coming...

D.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of tianye@sina
Sent: Sunday, November 25, 2018 9:10 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] About in-band telnet/ssh support of VPP

Hello Everyone:

As we all knows, the latest VPP version 18.10 support telnet.
We can set the conf file like this to monitor the remote telnet request:
unix {
  cli-listen localhost 5002 or cli-listen 192.168. 5002
  .

But actually the IP/Port pair we are listening is the "in-band" interface.
That means that interface belongs to the Linux host system(not the dedicate NIC 
pre-allocated for VPP)
Is there any solution for telnet/ssh toward the VPP in-band interface?
(Provide telnet/ssh support for in-band interface is very important when we 
managed to build a gateway/router device
over bare metal machine, since we cannot guarantee we can involve additional 
out-band interface with any topology and product cost limitation)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11429): https://lists.fd.io/g/vpp-dev/message/11429
Mute This Topic: https://lists.fd.io/mt/28320167/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] About in-band telnet/ssh support of VPP

[Dave Barach via Lists.Fd.Io]

Please do not use the vpp host stack to listen to port 23 (telnet) on a 
network-facing interface. You could do that, but please don't do that.

All you would need to add is a well-known default password, and you would have 
created a super-trivial attack surface for your product.

Florin and I are working to crank up sshd over the host stack. No guaranteed 
end-date, but it's coming...

D.

From: vpp-dev@lists.fd.io  On Behalf Of tianye@sina
Sent: Sunday, November 25, 2018 9:10 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] About in-band telnet/ssh support of VPP

Hello Everyone:

As we all knows, the latest VPP version 18.10 support telnet.
We can set the conf file like this to monitor the remote telnet request:
unix {
  cli-listen localhost 5002 or cli-listen 192.168. 5002
  .

But actually the IP/Port pair we are listening is the "in-band" interface.
That means that interface belongs to the Linux host system(not the dedicate NIC 
pre-allocated for VPP)
Is there any solution for telnet/ssh toward the VPP in-band interface?
(Provide telnet/ssh support for in-band interface is very important when we 
managed to build a gateway/router device
over bare metal machine, since we cannot guarantee we can involve additional 
out-band interface with any topology and product cost limitation)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11409): https://lists.fd.io/g/vpp-dev/message/11409
Mute This Topic: https://lists.fd.io/mt/28320167/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] Performance test issues : Average cpu time cost changes as the tx speed changes.

[Dave Barach via Lists.Fd.Io]

You just demonstrated one of the basic properties of vector packet processing: 
as the offered load increases, the cost per vector element decreases. Although 
you didn’t explicitly report the vector sizes involved, the vector size 
necessarily increases as the offered load increases. Anyhow, it’s easy to fish 
that that statistic out of the node runtime stats:


“clear run”

“show run”


You might ask: OK, why should the cost per packet decrease as the number of 
packets in a vector increases? When you first enter a dispatch function, none 
of the code involved is likely to be in the i-cache. The first packet incurs a 
bunch of fixed overhead to drag code into the i-cache, and to warm up the 
branch predictor. All of the other packets in the vector profit. On a 
per-packet basis, cost decreases as the vector size increases.

There are a number of secondary effects with the same net result. Until the 
vector size reaches 2, none of the graph nodes bother about prefetching. When 
dealing with quad-looped nodes: ‘s/2/4/’.

This property gives rise to a second interesting property: given a specific 
offered load and configuration, the vector size reaches a stable equilibrium. 
Imagine the circuit time in equilibrium. Add a small delay [clock interrupt at 
kernel level?] which increases the graph dispatch circuit time (rx ... process 
... tx ... repeat).

The next rx vector size will be larger, but since it will be processed more 
efficiently, the vector size will eventually return to the equilibrium value.

HTH... Dave


From: vpp-dev@lists.fd.io  On Behalf Of Mikado
Sent: Thursday, November 22, 2018 10:22 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Performance test issues : Average cpu time cost changes as 
the tx speed changes.

Hi,
Recently I’m developing a plugin based on VPP 18.07 to decode specified 
packets. I added it between dpdk-input and interface-output  using the same 
method of adding sample plugin in VPP source code. To test its performance in 
theory , I used  clib_cpu_time_now() to calculate the average cpu time cost  
when packets  go through my pulgin.When I use differnet tx speed to send 
packets to the device using VPP and my plugin , it  turns out  that the average 
cpu time changes as the tx speed changes. At frist , I assume it is caused by 
the cpu time cost when VPP moves packets to the next node. So I calculate the 
average cpu time of each node but it appears  the same.Then, I use the sample 
plugin to operate  the same test. The result is similar although it does not 
fluctuate much.
Now I’m confused. Isn’t it that all packets go through the same code and cost 
the same cpu time ?

Here is my code and test result.

Code added in sample/node.c:
static uword
sample_node_fn (vlib_main_t * vm,
  vlib_node_runtime_t * node,
  vlib_frame_t * frame)
{
  from = vlib_frame_vector_args (frame);
  n_left_from = frame->n_vectors;
  next_index = node->cached_next_index;

  sample_main.last_cpu_time = clib_cpu_time_now ();

  sample_main.total_pkts += n_left_from;
   ………
  while (n_left_from > 0){
   ………
   }
   ………
  vlib_node_increment_counter (vm, sample_node.index,
   SAMPLE_ERROR_SWAPPED, pkts_swapped);

  sample_main.total_cpu_time += clib_cpu_time_now() - sample_main.last_cpu_time;

  return frame->n_vectors;
}


Test result:
Tx speed(Mb/s)  Average cpu time
19014
47512
6659
9507
1140  7
1900  6
2895  6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11385): https://lists.fd.io/g/vpp-dev/message/11385
Mute This Topic: https://lists.fd.io/mt/28292345/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] Difference between PRE_INPUT and INPUT nodes

[Dave Barach via Lists.Fd.Io]

Try setting the node state to VLIB_NODE_STATE_DISABLED on the main thread:

Vlib_node_state_state (vlib_mains[0] or _global_main, ...):


/** \brief Set node dispatch state.
 @param vm vlib_main_t pointer, varies by thread
 @param node_index index of the node
 @param new_state new state for node, see vlib_node_state_t
*/
void vlib_node_set_state (vlib_main_t * vm, u32 node_index, vlib_node_state_t 
new_state)

-Original Message-
From: Prashant Upadhyaya  
Sent: Thursday, November 22, 2018 8:53 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

Thanks Dave.
I used the VLIB_NODE_TYPE_INPUT, but I now observe that, in presence of worker 
threads, my main thread is going to 100 % cpu utilization as well.
Without my new node, the main thread does not go to 100 % cpu utilization.
I want the polling to happen only in worker threads (or the main thread if 
there are no workers) Can I do something at the runtime to achieve that ?

Regards
-Prashant

On Thu, Nov 22, 2018 at 7:02 PM Dave Barach (dbarach)  wrote:
>
> Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist to 
> make sure that a certain epoll(...) call happens at the top of the loop.
>
> D.
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Thursday, November 22, 2018 7:41 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes
>
> Hi,
>
> What is the difference between --
> .type = VLIB_NODE_TYPE_PRE_INPUT
> and
> .type = VLIB_NODE_TYPE_INPUT
>
> when the --
> .state = VLIB_NODE_STATE_POLLING
>
> Typically when should the PRE_INPUT be used and when the INPUT, would 
> appreciate any advice on this. My usecase needs to do a high speed polling.
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11368): https://lists.fd.io/g/vpp-dev/message/11368
Mute This Topic: https://lists.fd.io/mt/28286049/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] Difference between PRE_INPUT and INPUT nodes

[Dave Barach via Lists.Fd.Io]

Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist to 
make sure that a certain epoll(...) call happens at the top of the loop.

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Thursday, November 22, 2018 7:41 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

Hi,

What is the difference between --
.type = VLIB_NODE_TYPE_PRE_INPUT
and
.type = VLIB_NODE_TYPE_INPUT

when the --
.state = VLIB_NODE_STATE_POLLING

Typically when should the PRE_INPUT be used and when the INPUT, would 
appreciate any advice on this. My usecase needs to do a high speed polling.

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

View/Reply Online (#11365): https://lists.fd.io/g/vpp-dev/message/11365
Mute This Topic: https://lists.fd.io/mt/28286049/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] Getting crash while running load on VPP18.01 for 6 hours

[Dave Barach via Lists.Fd.Io]

See 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing_Code_with_git_review

From: chetan bhasin 
Sent: Tuesday, November 20, 2018 11:43 AM
To: Dave Barach (dbarach) 
Subject: Re: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Thanks Dave!

I will try with DEBUG too.

Just want to understand the procedure to check in the patches,  actually we 
have done several fixes in VPP,  so we are planning to Check-in all patches.

Thanks,
Chetan Bhasin

On Tue, Nov 20, 2018, 18:02 Dave Barach (dbarach) 
mailto:dbar...@cisco.com> wrote:
Several suggestions:


  *   Try a debug image (PLATFORM=vpp TAG=vpp_debug) so the crash will be more 
enlightening
  *   Switch to 18.10. 18.01 is no longer supported. We don’t use the mheap.c 
memory allocator anymore, and so on and so forth.
  *   See https://wiki.fd.io/view/VPP/BugReports


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of chetan bhasin
Sent: Tuesday, November 20, 2018 5:31 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Hi Vpp-dev,

We are facing issues while running load for ~6 hours . getting below crash.

Your Suggestion is really appreciated.


#1  0x2b00b990e8f8 in __GI_abort () at abort.c:90
#2  0x00405f23 in os_panic () at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268
#3  0x2b00b8d60710 in mheap_put (v=0x2b00ba3d8000, uoffset=2382207096) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mheap.c:798
#4  0x2b00b8d8959e in clib_mem_free (p=0x2b00c8ba84a0) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:213
#5  vec_resize_allocate_memory (v=, 
length_increment=length_increment@entry=1, data_bytes=, 
header_bytes=, header_bytes@entry=0, 
data_align=data_align@entry=4) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/vec.c:96
#6  0x2b00b79e899d in _vec_resize (data_align=, 
header_bytes=, data_bytes=, 
length_increment=, v=) at 
/nfs-bfs/workspace/build-data/../src/vppinfra/vec.h:142
#7  get_frame_size_info (n_scalar_bytes=, 
n_vector_bytes=, nm=0x2b00c87a3160, nm=0x2b00c87a3160) at 
/nfs-bfs/workspace//build-data/../src/vlib/main.c:107
#8  0x2b00b79e8d79 in vlib_frame_free (vm=vm@entry=0x2b00c87a3050, 
r=r@entry=0x2b00c86ca368, f=f@entry=0x2b014b2ecb80) at 
/nfs-bfs//vpp_1801/build-data/../src/vlib/main.c:221
#9  0x2b00b79fe6e6 in null_node_fn (vm=0x2b00c87a3050, node=0x2b00c86ca368, 
frame=0x2b014b2ecb80) at /nfs-bfs/workspace/build-data/../src/vlib/node.c:512

Thanks,
Chetan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11341): https://lists.fd.io/g/vpp-dev/message/11341
Mute This Topic: https://lists.fd.io/mt/28266210/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] VPP crashes out of vlib_worker_thread_barrier_sync_int while workers stuck in clib_bihash_add_del

[Dave Barach via Lists.Fd.Io]

See previous email about 18.01 support. Much has changed in the code base in 
the last year. You would be well-advised to move to 18.10 at your earliest 
possible convenience.

To start working out what’s wrong: grab one of the worker threads in gdb, and 
see what it’s doing. Possibilities include waiting for the bihash writer lock, 
I suppose. I can’t say that I’ve ever seen this kind of failure.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of siddarth rai
Sent: Tuesday, November 20, 2018 3:38 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP crashes out of vlib_worker_thread_barrier_sync_int while 
workers stuck in clib_bihash_add_del

Hi,
I am using VPP version v18.01.1-100~g3a6948c.

VPP sometimes crashes out of vlib_worker_thread_barrier_sync_int when running 
with load.

Here is the back trace :
(gdb) bt
#0  0x2b9e5d45d207 in raise () from /lib64/libc.so.6
#1  0x2b9e5d45e8f8 in abort () from /lib64/libc.so.6
#2  0x00405f23 in os_panic () at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268
#3  0x2b9e5b55c7ea in vlib_worker_thread_barrier_sync_int 
(vm=0x2b9e5b78c260 )
at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/threads.c:1488
#4  0x2b9e5b2d6e2a in vl_msg_api_handler_with_vm_node (am=0x2b9e5b5084a0 
, the_msg=0x304d0b2c, vm=0x2b9e5b78c260 , 
node=)
at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlibapi/api_shared.c:506
#5  0x2b9e5b2e645c in memclnt_process (vm=0x2b9e5b78c260 
, node=0x2b9e5e008000, f=)
at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/memory_vlib.c:987
#6  0x2b9e5b5386e6 in vlib_process_bootstrap (_a=) at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1231
#7  0x2b9e5c8a48b8 in clib_calljmp () at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/longjmp.S:110
#8  0x2b9e60327e30 in ?? ()
#9  0x2b9e5b539a59 in vlib_process_startup (f=0x0, p=0x2b9e5e008000, 
vm=0x2b9e5b78c260 )
at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1253
#10 dispatch_process (vm=0x2b9e5b78c260 , p=0x2b9e5e008000, 
last_time_stamp=3140570395200949, f=0x0)
at 
/bfs-build//2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1296
#11 0x in ?? ()


Some of the worker threads seem to be stuck in Bihash add_del operation ( part 
of out implementation )

(gdb) info thr
  Id   Target Id Frame
  7Thread 0x2ba2f991a700 (LWP 69610) 0x2ba0e08cd184 in 
clib_bihash_add_del_40_8 (h=0x2b9e6050d030, add_v=0x2b9ea5ed8cf8,
is_add=) at /spare/include/vppinfra/bihash_template.c:338
...
  5Thread 0x2ba2f9317700 (LWP 69607) 0x2ba0e08cd184 in 
clib_bihash_add_del_40_8 (h=0x2b9e6050cc10, add_v=0x2b9e7ca45620,
is_add=) at 
/spare/srai/include/vppinfra/bihash_template.c:338
...

Is it possible for worker threads to be stuck at this place for some reason? 
Any help would be appreciated.


Thanks,
Siddarth

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

View/Reply Online (#11337): https://lists.fd.io/g/vpp-dev/message/11337
Mute This Topic: https://lists.fd.io/mt/28265837/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] Getting crash while running load on VPP18.01 for 6 hours

[Dave Barach via Lists.Fd.Io]

Several suggestions:


  *   Try a debug image (PLATFORM=vpp TAG=vpp_debug) so the crash will be more 
enlightening
  *   Switch to 18.10. 18.01 is no longer supported. We don’t use the mheap.c 
memory allocator anymore, and so on and so forth.
  *   See https://wiki.fd.io/view/VPP/BugReports


From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Tuesday, November 20, 2018 5:31 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Hi Vpp-dev,

We are facing issues while running load for ~6 hours . getting below crash.

Your Suggestion is really appreciated.


#1  0x2b00b990e8f8 in __GI_abort () at abort.c:90
#2  0x00405f23 in os_panic () at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268
#3  0x2b00b8d60710 in mheap_put (v=0x2b00ba3d8000, uoffset=2382207096) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mheap.c:798
#4  0x2b00b8d8959e in clib_mem_free (p=0x2b00c8ba84a0) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:213
#5  vec_resize_allocate_memory (v=, 
length_increment=length_increment@entry=1, data_bytes=, 
header_bytes=, header_bytes@entry=0, 
data_align=data_align@entry=4) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/vec.c:96
#6  0x2b00b79e899d in _vec_resize (data_align=, 
header_bytes=, data_bytes=, 
length_increment=, v=) at 
/nfs-bfs/workspace/build-data/../src/vppinfra/vec.h:142
#7  get_frame_size_info (n_scalar_bytes=, 
n_vector_bytes=, nm=0x2b00c87a3160, nm=0x2b00c87a3160) at 
/nfs-bfs/workspace//build-data/../src/vlib/main.c:107
#8  0x2b00b79e8d79 in vlib_frame_free (vm=vm@entry=0x2b00c87a3050, 
r=r@entry=0x2b00c86ca368, f=f@entry=0x2b014b2ecb80) at 
/nfs-bfs//vpp_1801/build-data/../src/vlib/main.c:221
#9  0x2b00b79fe6e6 in null_node_fn (vm=0x2b00c87a3050, node=0x2b00c86ca368, 
frame=0x2b014b2ecb80) at /nfs-bfs/workspace/build-data/../src/vlib/node.c:512

Thanks,
Chetan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11336): https://lists.fd.io/g/vpp-dev/message/11336
Mute This Topic: https://lists.fd.io/mt/28266210/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] VPP coredump question

[Dave Barach via Lists.Fd.Io]

See https://wiki.fd.io/view/VPP/BugReports "Core Files" section.

From: vpp-dev@lists.fd.io  On Behalf Of Rubina Bianchi
Sent: Monday, November 19, 2018 8:05 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP coredump question

Hi Dear VPP

I have two question about vpp coredump.
How can I use full-coredump parameter in my startup.conf to make a dump if vpp 
crashes?
After crash, where this dump will be saved?

Here is my startup.conf:
unix {
nodaemon
log /tmp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
startup-config /etc/vpp/init.conf
}

api-trace {
on
}

api-segment {
gid vpp
}

cpu {
main-core 1
corelist-workers 2
workers 1
}

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

View/Reply Online (#11314): https://lists.fd.io/g/vpp-dev/message/11314
Mute This Topic: https://lists.fd.io/mt/28241075/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] ip4-load-balance

[Dave Barach via Lists.Fd.Io]

+1, "vpp# show hardware" and "$ cat /proc/cpuinfo" to make sure that the 
selected cores are on the right NUMA socket...

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Vratko Polak -X 
(vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Wednesday, November 14, 2018 11:51 AM
To: Ray Kinsella ; vpp-dev@lists.fd.io; Neale Ranns (nranns) 
; Damjan Marion (damarion) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] ip4-load-balance

> Any clues as to what might causing the delta?
>> using FD.io VPP 18.07

If you are still using that,
the performance might depend on the NUMA node used.
There was a placement bug, and the fix [1] has been merged just before 18.10.

Vratko.

[1] https://gerrit.fd.io/r/15483

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ray Kinsella
Sent: Wednesday, 2018-November-14 15:03
To: vpp-dev@lists.fd.io; Neale Ranns (nranns) ; Damjan Marion 
(damarion) 
Subject: Re: [vpp-dev] ip4-load-balance

CSIT is measuring roughly 12mpps on HSW.
When I measure with an equivalent system I get 10.5mpps on HSW.

What I am finding is that DPDK is more efficient on CSIT HSW.

CSIT
Graph Node  Clocks/Vector
dpdk-input  6.07e1
TenGigabitEtherneta/0/0-tx  4.09e1

My System
dpdk-input  8.30e1
TenGigabitEthernet83/0/1-tx 5.51e1

So between TX and Input, I am burning an extra 30 Clocks per vector.
That ends up being the essential difference between 10.5mpps and 12mpps.

I tried this with both binaries I built myself and the binaries in package 
cloud, and I get the same result.

Any clues as to what might causing the delta?
(I verified that my system setup was equivalent to CSIT)

startup.conf @ https://pastebin.com/tuYZ6xt8

Ray K

On 13/11/2018 18:09, Ray Kinsella wrote:
> Mystery solved,
> 
> I was missing the interface on the IP Route.
> 
> ip route add count 1 20.20.20.0/24 via 1.1.1.2
> TenGigabitEthernet83/0/1
> 
> Ray K
> 
> On 13/11/2018 15:39, Ray Kinsella wrote:
>> Folks,
>>
>> I have configuring my system to get something comparable to CSIT 
>> performance and I am a few mpps off at the moment, using FD.io VPP 18.07.
>>
>> I duplicated the IPv4 Base and Scale Test Cases (and environment) 
>> locally and I end up with extra graph node 'ip4-load-balance' in my 
>> pipeline?
>>
>> CSIT records the following pipeline in Test Operation Data.
>> https://docs.fd.io/csit/rls1807/report/test_operational_data
>>
>> Thread 1 vpp_wk_0 (lcore 2)
>>   Time 5.7, average vectors/node 245.79, last 128 main loops 13.03 
>> per node 151.64
>>     vector rates in 1.2082e7, out 1.2082e7, drop 0.e0, punt 0.e0
>>    Name State Calls  
>> Vectors     Suspends Clocks   Vectors/Call
>>   TenGigabitEtherneta/0/0-output   active 140125
>> 34429184   0  8.41e0  245.70
>>   TenGigabitEtherneta/0/0-tx   active 140125
>> 34429184   0  4.09e1  245.70
>>   TenGigabitEtherneta/0/1-output   active 140071
>> 34428928   0  8.58e0  245.79
>>   TenGigabitEtherneta/0/1-tx   active 140071
>> 34428928   0  3.93e1  245.79
>>   dpdk-input   polling    140580
>> 68858112   0  6.07e1  489.81
>>   ip4-input-no-checksum    active 280127
>> 68858112   0  2.05e1  245.81
>>   ip4-lookup   active 280127
>> 68858112   0  3.03e1  245.81
>>   ip4-rewrite  active 280127
>> 68858112   0  2.92e1  245.81
>>
>>
>> I get the following pipeline, with the additional graph node - 
>> ip4-load-balance.
>>
>> Thread 2 vpp_wk_1 (lcore 20)
>> Time 188.9, average vectors/node 256.00, last 128 main loops 14.00 
>> per node 256.00
>>    vector rates in 9.3287e6, out 9.3287e6, drop 0.e0, punt 0.e0
>>   Name State Calls  
>> Vectors    Suspends Clocks   Vectors/Call 
>> TenGigabitEthernet83/0/1-outpu   active    6881842
>> 1761751552   0  8.46e0  256.00 
>> TenGigabitEthernet83/0/1-tx  active    6881842
>> 1761751552   0  5.53e1  256.00 dpdk-input 
>> polling   6881842
>> 1761751552   0  8.58e1  256.00 
>> ip4-input-no-checksum    active    6881842
>> 1761751552   0  2.19e1  256.00 
>> ip4-load-balance active    6881842
>> 1761751552   0  1.68e1  25
>> 6.00
>> ip4-lookup   active    6881842
>> 1761751552   0  2.80e1  256.00 
>> ip4-rewrite  

Re: [vpp-dev] VPP not starting under centos on VIRL

[Dave Barach via Lists.Fd.Io]

Try fixing this problem, reported in the Jenkins job log:


Identified problems


virl nfs mount failure

virl simulated node not mounting nfs directory properly
Indication 
1



From: vpp-dev@lists.fd.io  On Behalf Of Jan Gelety via 
Lists.Fd.Io
Sent: Tuesday, November 13, 2018 4:40 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP not starting under centos on VIRL

Hello,

last runs of csit semi-weekly job [0] that verifies newest available vpp builds 
failed because vpp didn't start correctly:

09:49:13.792

TRACE

exec_command on ('10.30.53.124', 22) with timeout 30: sudo -S vppctl show pci


09:49:13.895

TRACE

exec_command on ('10.30.53.124', 22) took 0.103289842606 seconds


09:49:13.895

TRACE

return RC 1


09:49:13.896

TRACE

return STDOUT


09:49:13.896

TRACE

return STDERR clib_socket_init: connect (fd 3, '/run/vpp/cli.sock'): No such 
file or directory


During vpp startup we can see following (sudo -S journalctl --no-pager 
--unit=vpp --since="$(echo `systemctl show -p ActiveEnterTimestamp vpp` | awk 
'{print $2 $3}')"):

Nov 12 03:49:12 sut1 vpp[1455]: load_one_plugin:145: libmbedcrypto.so.2: cannot 
open shared object file: No such file or directory
Nov 12 03:49:12 sut1 vpp[1455]: load_one_plugin:146: Failed to load plugin 
'tlsmbedtls_plugin.so'
Nov 12 03:49:12 sut1 vpp[1455]: load_one_plugin:189: Loaded plugin: 
tlsopenssl_plugin.so (openssl based TLS Engine)
Nov 12 03:49:12 sut1 vpp[1455]: load_one_plugin:117: Plugin disabled (default): 
unittest_plugin.so
Nov 12 03:49:12 sut1 vpp[1455]: load_one_plugin:189: Loaded plugin: 
vmxnet3_plugin.so (VMWare Vmxnet3 Device Plugin)
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: tls_init_ca_chain:748: 
Could not initialize TLS CA certificates
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: tls_openssl_init:819: 
failed to initialize TLS CA chain
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: tls_init_ca_chain:748: Could not 
initialize TLS CA certificates
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: tls_openssl_init:819: failed to 
initialize TLS CA chain
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: perfmon: Failed to read CPU-specific 
counter table
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: perfmon: Failed to read 
CPU-specific counter table
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: perfmon: Please install the 
vpp-dev package and then:
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: perfmon: cd 
/usr/share/vpp/plugins/perfmon; sudo tar Jxf PerfmonTables.tar.xz
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: perfmon: and restart vpp.
Nov 12 03:49:12 sut1 vpp[1455]: /usr/bin/vpp[1455]: unix_proc_file_contents: 
open `/usr/share/vpp/plugins/perfmon/haswell_core_v28.json':
No such file or directory Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: perfmon: 
Please install the vpp-dev package and then:
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: perfmon: cd 
/usr/share/vpp/plugins/perfmon; sudo tar Jxf PerfmonTables.tar.xz
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: perfmon: and restart vpp.
Nov 12 03:49:12 sut1 /usr/bin/vpp[1455]: unix_proc_file_contents: open 
`/usr/share/vpp/plugins/perfmon/haswell_core_v28.json': No such file or 
directory

Pacakges installed:
=
Package  Arch  Version Repository   
Size
=
vpp  x86_64 19.01-rc0~231_g8966638~b5521  installed 
   2.5 M
vpp-devel x86_64 19.01-rc0~231_g8966638~b5521  installed
12 M
vpp-lib  x86_64 19.01-rc0~231_g8966638~b5521  installed 
   12 M
vpp-plugins   x86_64 19.01-rc0~231_g8966638~b5521  installed
62 M
vpp-selinux-policyx86_64 19.01-rc0~231_g8966638~b5521  installed
85 k


Could somebody have a look on it, please?

Thanks,
Jan

[0] 
https://jenkins.fd.io/view/csit/job/csit-vpp-verify-master-centos7-semiweekly/

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

View/Reply Online (#11217): https://lists.fd.io/g/vpp-dev/message/11217
Mute This Topic: https://lists.fd.io/mt/28121329/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 dead client scan in shared memory interface (vl api)

[Dave Barach via Lists.Fd.Io]

Please submit this as a draft patch, and add me as a reviewer. Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Monday, November 12, 2018 1:21 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding dead client scan in shared memory interface (vl 
api)

Hi,

A developer in my team has suggested a fix in memory_vlib.c (VPP 18.01), I am 
attaching the base and modified file. This is related to dead client scan.

At a high level, the fix seems to be doing some additional cleanup when a dead 
client is detected. The intention is not to leak the memory over the shared 
memory interface.
Unfortunately I am not very intimately familiar with the mechanics of the data 
structures here, so if some experts in this area can do a diff of the attached 
files and advise me if the fix makes any sense, that will be really great.

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

View/Reply Online (#11205): https://lists.fd.io/g/vpp-dev/message/11205
Mute This Topic: https://lists.fd.io/mt/28088480/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 communication from main thread to worker threads

[Dave Barach via Lists.Fd.Io]

Yes, it should be easy to cherry-pick into any release where it's needed. 
HTH... Dave

-Original Message-
From: Prashant Upadhyaya  
Sent: Sunday, November 11, 2018 3:05 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding communication from main thread to worker 
threads

Thanks Dave !
I could figure out the vm->worker_thread_main_loop_callback with your hint.
It seems to be a newer feature, but looks to be quite easily back portable to 
older releases as well -- introduce the field and call it from the main loop.

So I could setup a piece of memory as the request message and reply message, 
set the request message in my main thread, point the callback of vm[i] to the 
desired function to be called in the worker, the worker does what it has to do 
and sets up the reply message and nulls out the callback, the main thread can 
poll for the reply to arrive with a field there and voila !

Many thanks for adding this feature !

Regards
-Prashant


On Sun, Nov 11, 2018 at 6:46 PM Dave Barach (dbarach)  wrote:
>
> Check out src/plugins/perfmon/perfmon_periodic.c for one take on that 
> problem...
>
> Dave
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Sunday, November 11, 2018 2:37 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding communication from main thread to worker 
> threads
>
> Hi,
>
> The function, vl_api_rpc_call_main_thread, is useful to do message transfer 
> from worker thread to the main thread.
>
> Is there any mechanism where I can call a function in worker thread from the 
> main thread ? That is, just the reverse of the above.
>
> I can use interrupts (vlib_node_set_interrupt_pending) but I can't send any 
> data with the interrupt I suppose.
>
> So basically I want to find out if there is any infra available where I can 
> send some data to my worker thread from the main thread instead of creating a 
> frame of data and enqueueing it the normal way to the worker towards a node.
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11197): https://lists.fd.io/g/vpp-dev/message/11197
Mute This Topic: https://lists.fd.io/mt/28079125/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 communication from main thread to worker threads

[Dave Barach via Lists.Fd.Io]

Check out src/plugins/perfmon/perfmon_periodic.c for one take on that problem...

Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Sunday, November 11, 2018 2:37 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding communication from main thread to worker threads

Hi,

The function, vl_api_rpc_call_main_thread, is useful to do message transfer 
from worker thread to the main thread.

Is there any mechanism where I can call a function in worker thread from the 
main thread ? That is, just the reverse of the above.

I can use interrupts (vlib_node_set_interrupt_pending) but I can't send any 
data with the interrupt I suppose.

So basically I want to find out if there is any infra available where I can 
send some data to my worker thread from the main thread instead of creating a 
frame of data and enqueueing it the normal way to the worker towards a node.

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

View/Reply Online (#11195): https://lists.fd.io/g/vpp-dev/message/11195
Mute This Topic: https://lists.fd.io/mt/28079125/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] vlib_buffer_alloc error

[Dave Barach via Lists.Fd.Io]

Dear Ewan,

Please consider moving to vpp 18.10. 17.04 is not supported anymore.

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of xulang
Sent: Saturday, November 10, 2018 4:37 AM
To: xulang 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vlib_buffer_alloc error

My version is 17.04.




At 2018-11-10 16:38:17, "xulang" mailto:xlang...@163.com>> 
wrote:

Hi all,

Sometimes(pretty many times), we get strange buffer index and which can cause 
fatal problem to vpp when we use ipsec vpn.
Here are some details in function fill_free_list:

(gdb) p mb0
$31 = (struct rte_mbuf *) 0x7f4a796e3740
(gdb) p mb1
$32 = (struct rte_mbuf *) 0x7f4a796e2d00
(gdb) p mb2
$33 = (struct rte_mbuf *) 0x7f4a796e22c0
(gdb) p mb3
$34 = (struct rte_mbuf *) 0x7f4a796e1880

(gdb) p b1
$29 = (vlib_buffer_t *) 0x7f4a796e2d80
(gdb) p b0
$30 = (vlib_buffer_t *) 0x7f4a796e37c0
(gdb) p b2
$27 = (vlib_buffer_t *) 0x7f4a796e2340
(gdb) p b3
$28 = (vlib_buffer_t *) 0x7f4a796e1900
(gdb) p bi0
$21 = 3281633096
(gdb) p bi1
$22 = 32586
(gdb) p bi2
$25 = 84176
(gdb) p bi3
$26 = 84135

Those buffers address are right, but the buffed indexes are quite strange.
Any clue or suggestion here?


(gdb)
fill_free_list (min_free_buffers=1, fl=0x7f4ac36eee40, vm=0x7f4b07dcf2c0 
)
at 
/home/vbras/codenew/VBRASV100R001_new_trunk/vpp1704/build-data/../src/plugins/dpdk/buffer.c:238
238 vec_add1_aligned (fl->buffers, bi0, CLIB_CACHE_LINE_BYTES);
(gdb)
233 bi0 = vlib_get_buffer_index (vm, b0);

(gdb) call sizeof(struct rte_mbuf)
$35 = 128


Regards,
Ewan




【网易自营|30天无忧退货】网易严选11.11开抢：3.9元色画主义人字拖，68元一套CEO丁磊推荐咖啡碳保暖内衣，先到先得售罄不补>> 

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

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

[vpp-dev] New Committer Nomination: Andrew Yourtchenko

[Dave Barach via Lists.Fd.Io]

In view of significant code contributions to the vpp project - see below - I'm 
pleased to nominate Andrew Yourtchenko as a vpp project committer. I have high 
confidence that he'll be a major asset to the project in a committer role.  

Andrew has contributed 181 merged patches, including significant new feature 
work in the ACL plugin. Example: https://gerrit.fd.io/r/#/c/13162
 
Committers, please vote (+1, 0, -1) on vpp-dev@ We'll need a recorded vote 
so that the TSC will approve Andrew's nomination.

Thanks... Dave

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

View/Reply Online (#11158): https://lists.fd.io/g/vpp-dev/message/11158
Mute This Topic: https://lists.fd.io/mt/28035544/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] vppctl issue

[Dave Barach via Lists.Fd.Io]

+1.

If the vpp service is running - and you're using the distributed version of 
/etc/vpp/startup.conf - you'll see this stanza:

api-segment {
  gid vpp
}

Make sure that the user running vppctl is either in the vpp group, or is root.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Wednesday, November 7, 2018 4:48 AM
To: 'Kevin Yan' ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vppctl issue

Check if VPP is running properly, "service vpp status" if its installed using 
the binaries. It normally occurs when the VPP service is not running.

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Kevin Yan
Sent: Wednesday, November 7, 2018 2:10 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vppctl issue

Hello,
 Does anyone met below errors when using vppctl and what is the possible 
reason?

clib_socket_init: connect (fd 3, '/run/vpp/cli.sock'): Connection refused

  BTW,  I changed a little vpp code but I suppose it doesn't not related to 
this issue and VPP itself is started without any problem

My startup configuration:

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

unix {
nodaemon
log /tmp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
}

dpdk {
socket-mem 2048
uio-driver uio_pci_generic
dev :00:06.0 {
num-rx-queues 2
num-tx-queues 2
}
dev :00:09.0
vdev cryptodev_aesni_mb_pmd,socket_id=0
vdev cryptodev_aesni_mb_pmd,socket_id=0
}

api-trace {
on
}

tap-inject {
enable
}


BRs,
Kevin



This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to 
secur...@mavenir.com. This message contains the 
views of its author and may not necessarily reflect the views of Mavenir 
Systems, Inc. or its affiliates, who employ systems to monitor email messages, 
but make no representation that such messages are authorized, secure, 
uncompromised, or free from computer viruses, malware, or other defects. Thank 
You
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11138): https://lists.fd.io/g/vpp-dev/message/11138
Mute This Topic: https://lists.fd.io/mt/28021014/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] About memory debug

[Dave Barach via Lists.Fd.Io]

Sure: go look at .../src/vppinfra/{dlmalloc.[ch], mheap.[ch]}

From: vpp-dev@lists.fd.io  On Behalf Of tianye@sina
Sent: Monday, November 5, 2018 9:23 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] About memory debug

So, everybody here debug the memory issue only with code review? :)
That does not make sense,  right?
so would you please share something for me?


From: tianye@sina [mailto:tiany...@sina.com]
Sent: Monday, November 5, 2018 9:53 AM
To: 'vpp-dev@lists.fd.io'
Subject: About memory debug

Hello Everyone：

As we all knows, the VPP platform is an intensive memory utilizing platform.
VPP handles a large number of memory buffers/caches and other wrapped memory 
blocks.
Is there some facility to help developers debug the memory related bugs/issues?
For some classic memory related bugs like memory leakage, out of boundary 
access(overrun) etc.

A old memory overrun issue debug tool is libmcheckb.so, it is made by Mike 
Haertel(A.K.A the author of grep) in 1989.
Is there something like this in VPP project or other related project?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11128): https://lists.fd.io/g/vpp-dev/message/11128
Mute This Topic: https://lists.fd.io/mt/27857742/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] Incrementing node counters

[Dave Barach via Lists.Fd.Io]

You’ll have to look at the instruction stream in gdb or else “gcc –S” and look 
at the generated assembly-language code. Even at that, the difference in clock 
cycles won’t be completely obvious due to subarchitectural CPU implementation 
details. “Node” is not a typical hot variable which would end up in a register. 
It probably makes exactly zero difference.

FWIW… Dave 

From: Kingwel Xie 
Date: Saturday, November 3, 2018 at 3:57 AM
To: Recipient Suppressed , "vpp-dev@lists.fd.io" 

Subject: RE: Incrementing node counters

Thanks for the comments. 

I know is_ip6 will be optimized by complier. 

I am still wondering how different between using xxx_node.index and 
node->node_index. Anyway,thanks, now I understand it is a performance 
consideration.

Best Regards,
Kingwel

 原始邮件 
主题： RE: Incrementing node counters
来自： "Dave Barach (dbarach)" 
发至： 2018年11月2日 下午7:00
抄送： Kingwel Xie ,vpp-dev@lists.fd.io
Yes, you missed something. This pattern is used in inline functions called with 
compile-time constant values for is_ip6:  
 
always_inline uword
ah_encrypt_inline (vlib_main_t * vm,
      vlib_node_runtime_t * node, vlib_frame_t * from_frame,
      int is_ip6)
 
 
VLIB_NODE_FN (ah4_encrypt_node) (vlib_main_t * vm,
 vlib_node_runtime_t * node,
 vlib_frame_t * from_frame)
{
  return ah_encrypt_inline (vm, node, from_frame, 0 /* is_ip6 */ );
}
 
 
 
VLIB_NODE_FN (ah6_encrypt_node) (vlib_main_t * vm,
 vlib_node_runtime_t * node,
 vlib_frame_t * from_frame)
{
  return ah_encrypt_inline (vm, node, from_frame, 1 /* is_ip6 */ );
}
 
The compiler discards either the “if” clause or the “else” clause, and 
(certainly) never tests is_ip6 at runtime. It might be marginally worth 
s/xxx_node.index/node->node_index/.
 
Another instance of this game may make sense in performance-critical nodes. 
Here, we remove packet-tracer code: 
 
always_inline uword
nsim_inline (vlib_main_t * vm,
  vlib_node_runtime_t * node, vlib_frame_t * frame, int is_trace)
{
  
  if (is_trace)
 {
   if (b[0]->flags & VLIB_BUFFER_IS_TRACED)
     {
   nsim_trace_t *t = vlib_add_trace (vm, node, b[0], sizeof (*t));
   t->expires = expires;
   t->is_drop = is_drop0;
   t->tx_sw_if_index = (is_drop0 == 0) ? ep->tx_sw_if_index : 0;
     }
 }
  
}
 
VLIB_NODE_FN (nsim_node) (vlib_main_t * vm, vlib_node_runtime_t * node,
      vlib_frame_t * frame)
{
  if (PREDICT_FALSE (node->flags & VLIB_NODE_FLAG_TRACE))
    return nsim_inline (vm, node, frame, 1 /* is_trace */ );
  else
    return nsim_inline (vm, node, frame, 0 /* is_trace */ );
}
 
From: vpp-dev@lists.fd.io  On Behalf Of Kingwel Xie
Sent: Thursday, November 1, 2018 8:43 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Incrementing node counters
 
Hi vPPers,
 
I’m looking at the latest changes in IPSEC, and I notice ip4 and ip6 nodes are 
separated. So there are a lot of code in the node function like this:
 
  if (is_ip6)
    vlib_node_increment_counter (vm, esp6_decrypt_node.index,
    
ESP_DECRYPT_ERROR_RX_PKTS,
    
from_frame->n_vectors);
  else
    vlib_node_increment_counter (vm, esp4_decrypt_node.index,
    
ESP_DECRYPT_ERROR_RX_PKTS,
    
from_frame->n_vectors);
 
 
I’m wondering why not like this:
 
    vlib_node_increment_counter (vm, node->node_index,
    
ESP_DECRYPT_ERROR_RX_PKTS,
    
from_frame->n_vectors);
 
My understanding is that node functions are always dispatched with the correct 
node instances. Or do I miss something? BTW, nt just ipsec, quite some other 
nodes are written as the former.
 
Regards,
Kingwel


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

View/Reply Online (#11083): https://lists.fd.io/g/vpp-dev/message/11083
Mute This Topic: https://lists.fd.io/mt/27823101/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_buffer_alloc

[Dave Barach via Lists.Fd.Io]

See also 
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vnet.html#creating-packets-from-scratch
 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Friday, November 2, 2018 12:54 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding vlib_buffer_alloc

Hi,

When I allocate a buffer using the vlib_buffer_alloc, are the fields in the 
vlib_buffer_t guaranteed to be properly initialized (eg. with all zero values) 
or is there any obligation on the caller to initialize these because the values 
may be unpredictable ?

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

View/Reply Online (#11080): https://lists.fd.io/g/vpp-dev/message/11080
Mute This Topic: https://lists.fd.io/mt/27829857/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] Incrementing node counters

[Dave Barach via Lists.Fd.Io]

Yes, you missed something. This pattern is used in inline functions called with 
compile-time constant values for is_ip6:

always_inline uword
ah_encrypt_inline (vlib_main_t * vm,
  vlib_node_runtime_t * node, vlib_frame_t * from_frame,
  int is_ip6)


VLIB_NODE_FN (ah4_encrypt_node) (vlib_main_t * vm,
 vlib_node_runtime_t * node,
 vlib_frame_t * from_frame)
{
  return ah_encrypt_inline (vm, node, from_frame, 0 /* is_ip6 */ );
}



VLIB_NODE_FN (ah6_encrypt_node) (vlib_main_t * vm,
 vlib_node_runtime_t * node,
 vlib_frame_t * from_frame)
{
  return ah_encrypt_inline (vm, node, from_frame, 1 /* is_ip6 */ );
}

The compiler discards either the “if” clause or the “else” clause, and 
(certainly) never tests is_ip6 at runtime. It might be marginally worth 
s/xxx_node.index/node->node_index/.

Another instance of this game may make sense in performance-critical nodes. 
Here, we remove packet-tracer code:

always_inline uword
nsim_inline (vlib_main_t * vm,
  vlib_node_runtime_t * node, vlib_frame_t * frame, int is_trace)
{
  
  if (is_trace)
 {
   if (b[0]->flags & VLIB_BUFFER_IS_TRACED)
 {
   nsim_trace_t *t = vlib_add_trace (vm, node, b[0], sizeof (*t));
   t->expires = expires;
   t->is_drop = is_drop0;
   t->tx_sw_if_index = (is_drop0 == 0) ? ep->tx_sw_if_index : 0;
 }
 }
  
}

VLIB_NODE_FN (nsim_node) (vlib_main_t * vm, vlib_node_runtime_t * node,
  vlib_frame_t * frame)
{
  if (PREDICT_FALSE (node->flags & VLIB_NODE_FLAG_TRACE))
return nsim_inline (vm, node, frame, 1 /* is_trace */ );
  else
return nsim_inline (vm, node, frame, 0 /* is_trace */ );
}

From: vpp-dev@lists.fd.io  On Behalf Of Kingwel Xie
Sent: Thursday, November 1, 2018 8:43 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Incrementing node counters

Hi vPPers,

I’m looking at the latest changes in IPSEC, and I notice ip4 and ip6 nodes are 
separated. So there are a lot of code in the node function like this:

  if (is_ip6)
vlib_node_increment_counter (vm, esp6_decrypt_node.index,

ESP_DECRYPT_ERROR_RX_PKTS,

from_frame->n_vectors);
  else
vlib_node_increment_counter (vm, esp4_decrypt_node.index,

ESP_DECRYPT_ERROR_RX_PKTS,

from_frame->n_vectors);


I’m wondering why not like this:

vlib_node_increment_counter (vm, node->node_index,

ESP_DECRYPT_ERROR_RX_PKTS,

from_frame->n_vectors);

My understanding is that node functions are always dispatched with the correct 
node instances. Or do I miss something? BTW, nt just ipsec, quite some other 
nodes are written as the former.

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

View/Reply Online (#11076): https://lists.fd.io/g/vpp-dev/message/11076
Mute This Topic: https://lists.fd.io/mt/27823101/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] Run failed on 1807 version vpp code on centos7.

[Dave Barach via Lists.Fd.Io]

# rm /dev/shm/* # and try it again.

From: vpp-dev@lists.fd.io  On Behalf Of ???
Sent: Wednesday, October 31, 2018 11:29 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Run failed on 1807 version vpp code on centos7.


Hi,


make run didn't seem to work,











Logs :
[root@localhost vpp]# ls
build-data  build-root  docs  doxygen  dpdk  extras  gmod  LICENSE  MAINTAINERS 
 Makefile  README.md  RELEASE.md  src  test  virtualenv
[root@localhost vpp]#
[root@localhost vpp]# make run
WARNING: STARTUP_CONF not defined or file doesn't exist.
 Running with minimal startup config:  unix { interactive cli-listen 
/run/vpp/cli.sock gid 0 } \n
vlib_plugin_early_init:361: plugin path 
/root/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins:/root/vpp/build-root/install-vpp_debug-native/vpp/lib64/vpp_plugins
load_one_plugin:189: Loaded plugin: abf_plugin.so (ACL based Forwarding)
load_one_plugin:189: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:189: Loaded plugin: avf_plugin.so (Intel Adaptive Virtual 
Function (AVF) Device Plugin)
load_one_plugin:191: Loaded plugin: cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:189: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group Based Policy)
load_one_plugin:189: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP messaging)
load_one_plugin:189: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:189: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:189: Loaded plugin: l2e_plugin.so (L2 Emulation)
load_one_plugin:189: Loaded plugin: lacp_plugin.so (Link Aggregation Control 
Protocol)
load_one_plugin:189: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:189: Loaded plugin: mactime_plugin.so (Time-based MAC 
source-address filter)
load_one_plugin:189: Loaded plugin: map_plugin.so (Mapping of address and port 
(MAP))
load_one_plugin:189: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:189: Loaded plugin: nat_plugin.so (Network Address Translation)
load_one_plugin:189: Loaded plugin: pppoe_plugin.so (PPPoE)
load_one_plugin:189: Loaded plugin: srv6ad_plugin.so (Dynamic SRv6 proxy)
load_one_plugin:189: Loaded plugin: srv6am_plugin.so (Masquerading SRv6 proxy)
load_one_plugin:189: Loaded plugin: srv6as_plugin.so (Static SRv6 proxy)
load_one_plugin:189: Loaded plugin: stn_plugin.so (VPP Steals the NIC for 
Container integration)
load_one_plugin:189: Loaded plugin: tlsopenssl_plugin.so (openssl based TLS 
Engine)
svm_map_region:748: region /global_vm mutex held by dead pid 10351, tag 2, 
force unlock
svm_map_region:756: recovery: attempt to re-lock region
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
...
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/root/vpp/build-data/../src/vppinfra/vec.h:134 (_vec_resize_inline) assertion 
`clib_mem_is_heap_object (p)' fails
/bin/sh: line 1: 10448 Segmentation fault  sudo 
/root/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp " unix { interactive 
cli-listen /run/vpp/cli.sock gid 0  }   "
make: *** [run] Error 139




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

View/Reply Online (#11064): https://lists.fd.io/g/vpp-dev/message/11064
Mute This Topic: https://lists.fd.io/mt/27812693/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] Snooping non-IP packets

[Dave Barach via Lists.Fd.Io]

When you register a feature node on the "device-input" arc, that node will 
receive EVERY packet on all interfaces which have the feature enabled... 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Monday, October 29, 2018 10:11 PM
To: Damjan Marion 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Snooping non-IP packets

Thanks Damjan !
Just to be sure, when I use the device-input feature arc thus --

VNET_FEATURE_INIT (myfeature, static) =
{
  .arc_name = "device-input",
  .node_name = "mynode",
  .runs_before = VNET_FEATURES ("ethernet-input"),
};

I get to see only the non-IP packets inside mynode, is that correct ?
I do get your point about sub-interfacing and that is fine.

Do the IPv4 and IPv6 packets go directly from dpdk-input to ip4-input and 
ip6-input, just to be sure ?

I also see a wiki link
https://wiki.fd.io/view/VPP/Feature_Arcs

It is mentioned there how to setup the next0 in mynode. I suppose doing a call 
to vnet_feature_next is a shortcut. Perhaps the wiki can mention that I think.

Regards
-Prashant



Regards
-Prashant



On Mon, Oct 29, 2018 at 11:31 PM Damjan Marion  wrote:
>
>
> Yes, you can just use device-input feature arc instead.
>
> Please note that packets on that arc are not (optionally) assigned to 
> sub-interfaces yet.
> So if you have vlan subinterface, packets will show up as main 
> interface packets and with original l2 header.
>
> --
> Damjan
>
> On 29 Oct 2018, at 18:22, Prashant Upadhyaya  wrote:
>
> Hi,
>
> I am using DPDK Plugin
> I want to write a node which will get to observe all the  non-IP packets.
> By observe, I mean that I want my node to see the non-IP packets, but 
> when I return from my node, the packets should traverse the original 
> graph of VPP which they would have followed had my node not been 
> there.
>
> I am wondering what's the best way to achieve the above.
> I have done VNET_FEATURE_INIT before using which eg. I got to observe 
> all the IPv4 packets by making my feature node sit on the ip4-unicast 
> arc and running before ip4-lookup.
>
> Can I do something similar for my requirement of observing all the 
> non-IP packets in a similar way or some other way, any advice would be 
> helpful.
>
> Regards
> -Prashant
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#11021): 
> https://lists.fd.io/g/vpp-dev/message/11021
> Mute This Topic: https://lists.fd.io/mt/27783711/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11037): https://lists.fd.io/g/vpp-dev/message/11037
Mute This Topic: https://lists.fd.io/mt/27783711/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] NAT44 && vxlan tunnel conflict

[Dave Barach via Lists.Fd.Io]

Please send the exact config you used, and the relevant packet tracer output.

From: wangchuan...@163.com 
Sent: Tuesday, October 30, 2018 1:13 AM
To: Dave Barach (dbarach) ; vpp-dev 
Subject: Re: RE: [vpp-dev] NAT44 && vxlan tunnel conflict

The attempt failed！  Adding static mapping to bvi or tap-in-OS both does not 
work.
Is there any cmd that can remove the NAT logic of udp-4789 from NAT44？

Help
please！


wangchuan...@163.com<mailto:wangchuan...@163.com>

From: Dave Barach (dbarach)<mailto:dbar...@cisco.com>
Date: 2018-10-29 22:25
To: wangchuan...@163.com<mailto:wangchuan...@163.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] NAT44 && vxlan tunnel conflict
The NAT plugin is tossing vxlan out-to-in packets. You’ll get different results 
if you add a static mapping for (UDP, 4789) packets – maybe not the desired 
result, but at least a different result...

D.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of 
wangchuan...@163.com<mailto:wangchuan...@163.com>
Sent: Monday, October 29, 2018 4:13 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] NAT44 && vxlan tunnel conflict

Hi all,
I want to login PC1 through SSH2 where vpp is running, and the VPP is used 
as the VXLAN translate center(only 1 ip).
However, I found some error!
Data from vxlan tunnel 1 were dropped, which should be decaped at one 
vxlan-tunnel-1 and transmited out from vxlan-tunnel-2.

How can I achieve my goal?
Help please!



#REMARK##



SSH:172.16.4.3  (SSH2)  172.16.4.2 (NAT44)---  192.168.120.2
VXLAN:172.16.4.177   (vxlan)  172.16.4.2  (NAT44)   --  
  drop

  ( desired： vxlan-decap -> br -> vxlan-encap -> 
TenGigabitEthernet6/0/0-tx ）

trace：
00:31:35:400543: dpdk-input
  TenGigabitEthernet6/0/0 rx queue 0
  buffer 0x12c31: current data 14, length 164, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14
  PKT MBUF: port 0, nb_segs 1, pkt_len 178
buf_len 2176, data_len 178, ol_flags 0x180, data_off 128, phys_addr 
0x708b0cc0
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
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:25:7c:30:05:ec -> 00:a0:c9:00:00:00
  UDP: 172.16.4.177 -> 172.16.4.2
tos 0x00, ttl 64, length 164, checksum 0x4902
fragment id 0x1743, flags DONT_FRAGMENT
  UDP: 4789 -> 4789
length 144, checksum 0x5ceb
00:31:35:400565: ip4-input-no-checksum
  UDP: 172.16.4.177 -> 172.16.4.2
tos 0x00, ttl 64, length 164, checksum 0x4902
fragment id 0x1743, flags DONT_FRAGMENT
  UDP: 4789 -> 4789
length 144, checksum 0x5ceb


00:31:35:400581: nat44-out2in
  NAT44_OUT2IN: sw_if_index 1, next index 0, session index -1
00:31:35:400596: error-drop
  nat44-out2in: No translation





configure cmd line*
set int state TenGigabitEthernet6/0/0 up
set int ip addr TenGigabitEthernet6/0/0 172.16.4.2/24

create bridge-domain  learn 1 forward 1 uu-flood 1 flood 1 arp-term 1
loopback create
set int l2 bridge loop0  bvi
set int ip address loop0 192.168.120.1/24
set int state loop0 up
tap connect tapOS address 192.168.120.2/24
set int l2 bridge tapcli-0 
set int state tapcli-0 up

create vxlan tunnel src 172.16.4.2 dst 172.16.4.177 vni 100
set interface l2 bridge vxlan_tunnel0 
create vxlan tunnel src 172.16.4.2 dst 172.16.4.188 vni 100
set interface l2 bridge vxlan_tunnel0 

nat44 add interface address TenGigabitEthernet6/0/0
set interface nat44 in loop0 out TenGigabitEthernet6/0/0
nat44 add static mapping local 192.168.120.2 22 external 
TenGigabitEthernet6/0/0 22 tcp


wangchuan...@163.com<mailto:wangchuan...@163.com>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11032): https://lists.fd.io/g/vpp-dev/message/11032
Mute This Topic: https://lists.fd.io/mt/27779539/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_buffer_t construction for tx of a self-made packet

[Dave Barach via Lists.Fd.Io]

Cool, glad you found what you needed... 

-Original Message-
From: Prashant Upadhyaya  
Sent: Monday, October 29, 2018 11:48 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding vlib_buffer_t construction for tx of a 
self-made packet

Thanks a bunch Dave !
The vlib_buffer_add_data(...) does the trick for me ! All that I really had to 
do was to just set up the following fields in the vlib_buffer_t for the buffer 
index created by the function  vnet_buffer (b)->sw_if_index[VLIB_RX]  
vnet_buffer (b)->sw_if_index[VLIB_TX]

What a nice function !



On Mon, Oct 29, 2018 at 4:50 AM Dave Barach (dbarach)  wrote:
>
> Look at .../src/vnet/ipfix-export/flow_report.c : send_template_packet(...) 
> for a decent example of most of the mechanics involved. Also look at 
> .../src/vlib/buffer.c : vlib_buffer_add_data(...).
>
> If you're going to send lots of such packets, it may well improve performance 
> to allocate a fair number of buffers at a time, and maintain a private buffer 
> cache. See ../src/vnet/tcp/tcp_output.c : tcp_alloc_tx_buffers(...).
>
> HTH... Dave
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Sunday, October 28, 2018 3:13 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding vlib_buffer_t construction for tx of a 
> self-made packet
>
> Hi,
>
> I have a situation where one of my plugins needs to construct an l2 packet 
> (containing an ip datagram inside).
> So I have a local buffer which contains the following bytes laid out 
> -- dst mac src mac ethertype ip header + payload
>
> Assume for the sake of generality that the above buffer is 4K bytes (because 
> I have an ip payload of that much size) Assume further that I magically 
> already know the sw if indices of the RX and TX.
> It is also ensured that the l2 paylod size is lesser than or equal to 
> the MTU of the TX interface
>
> Now once I have all of the above information, I need to create a 
> vlib_buffer_t (possibly a chained set) So I need some guidelines/best 
> practices of how to go about it flawlessly so that once the vlib_buffer_t is 
> constructed, I can simply send it to the "interface-output" and accomplish 
> the act of transmission.
>
> The high level set of things that I can think of is --
>
> 1. Allocate a vlib_buffer_t (or a chained flavour of those) 2. Start 
> appending data to those buffers 3. What about the various control fields to 
> be set in the above buffers ?
> . I suppose I will have to do the following --
>   vnet_buffer (b0)->sw_if_index[VLIB_RX] = ;
> vnet_buffer (b0)->sw_if_index[VLIB_TX] = ; Do 
> I need to do anything with b0->buffer_pool_index ?
> What to do with b0->current_data ?
> What to do with b0->flags ?
> What to do with b->current_length ?
> And if it is a chained set, what is to be done on individual vlib_buffer_t of 
> the chain and what on the first one of the chain ?
>
> I suppose I need a convenience function like the following
>
> vlib_buffer_t* foo(char* myl2packet, int lengthOfMyL2Packet, u32 
> mySwIfRxIndex, u32 mySwIfTxIndex)
>
> The above should return to me a nice little vlib_buffer_t (possibly
> chained) which I can then ship to interface output.
> I am willing to write such a function by all means but want to find out if 
> anything like this (or closer) already exists.
> If it doesn't exist, what idioms can I follow from the functions which 
> already exist and what I have to be careful about.
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11018): https://lists.fd.io/g/vpp-dev/message/11018
Mute This Topic: https://lists.fd.io/mt/27770677/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] NAT44 && vxlan tunnel conflict

[Dave Barach via Lists.Fd.Io]

The NAT plugin is tossing vxlan out-to-in packets. You’ll get different results 
if you add a static mapping for (UDP, 4789) packets - maybe not the desired 
result, but at least a different result...

D.

From: vpp-dev@lists.fd.io  On Behalf Of 
wangchuan...@163.com
Sent: Monday, October 29, 2018 4:13 AM
To: vpp-dev 
Subject: [vpp-dev] NAT44 && vxlan tunnel conflict

Hi all,
I want to login PC1 through SSH2 where vpp is running, and the VPP is used 
as the VXLAN translate center(only 1 ip).
However, I found some error!
Data from vxlan tunnel 1 were dropped, which should be decaped at one 
vxlan-tunnel-1 and transmited out from vxlan-tunnel-2.

How can I achieve my goal?
Help please!


#REMARK##


SSH:172.16.4.3  (SSH2)  172.16.4.2 (NAT44)---  192.168.120.2
VXLAN:172.16.4.177   (vxlan)  172.16.4.2  (NAT44)   --  
  drop

  ( desired： vxlan-decap -> br -> vxlan-encap -> 
TenGigabitEthernet6/0/0-tx ）

trace：
00:31:35:400543: dpdk-input
  TenGigabitEthernet6/0/0 rx queue 0
  buffer 0x12c31: current data 14, length 164, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14
  PKT MBUF: port 0, nb_segs 1, pkt_len 178
buf_len 2176, data_len 178, ol_flags 0x180, data_off 128, phys_addr 
0x708b0cc0
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
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:25:7c:30:05:ec -> 00:a0:c9:00:00:00
  UDP: 172.16.4.177 -> 172.16.4.2
tos 0x00, ttl 64, length 164, checksum 0x4902
fragment id 0x1743, flags DONT_FRAGMENT
  UDP: 4789 -> 4789
length 144, checksum 0x5ceb
00:31:35:400565: ip4-input-no-checksum
  UDP: 172.16.4.177 -> 172.16.4.2
tos 0x00, ttl 64, length 164, checksum 0x4902
fragment id 0x1743, flags DONT_FRAGMENT
  UDP: 4789 -> 4789
length 144, checksum 0x5ceb

00:31:35:400581: nat44-out2in
  NAT44_OUT2IN: sw_if_index 1, next index 0, session index -1
00:31:35:400596: error-drop
  nat44-out2in: No translation



configure cmd line*
set int state TenGigabitEthernet6/0/0 up
set int ip addr TenGigabitEthernet6/0/0 172.16.4.2/24

create bridge-domain  learn 1 forward 1 uu-flood 1 flood 1 arp-term 1
loopback create
set int l2 bridge loop0  bvi
set int ip address loop0 192.168.120.1/24
set int state loop0 up
tap connect tapOS address 192.168.120.2/24
set int l2 bridge tapcli-0 
set int state tapcli-0 up

create vxlan tunnel src 172.16.4.2 dst 172.16.4.177 vni 100
set interface l2 bridge vxlan_tunnel0 
create vxlan tunnel src 172.16.4.2 dst 172.16.4.188 vni 100
set interface l2 bridge vxlan_tunnel0 

nat44 add interface address TenGigabitEthernet6/0/0
set interface nat44 in loop0 out TenGigabitEthernet6/0/0
nat44 add static mapping local 192.168.120.2 22 external 
TenGigabitEthernet6/0/0 22 tcp


wangchuan...@163.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11016): https://lists.fd.io/g/vpp-dev/message/11016
Mute This Topic: https://lists.fd.io/mt/27779539/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_buffer_t construction for tx of a self-made packet

[Dave Barach via Lists.Fd.Io]

Look at .../src/vnet/ipfix-export/flow_report.c : send_template_packet(...) for 
a decent example of most of the mechanics involved. Also look at 
.../src/vlib/buffer.c : vlib_buffer_add_data(...).

If you're going to send lots of such packets, it may well improve performance 
to allocate a fair number of buffers at a time, and maintain a private buffer 
cache. See ../src/vnet/tcp/tcp_output.c : tcp_alloc_tx_buffers(...).

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Sunday, October 28, 2018 3:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding vlib_buffer_t construction for tx of a self-made 
packet

Hi,

I have a situation where one of my plugins needs to construct an l2 packet 
(containing an ip datagram inside).
So I have a local buffer which contains the following bytes laid out -- dst mac 
src mac ethertype ip header + payload

Assume for the sake of generality that the above buffer is 4K bytes (because I 
have an ip payload of that much size) Assume further that I magically already 
know the sw if indices of the RX and TX.
It is also ensured that the l2 paylod size is lesser than or equal to the MTU 
of the TX interface

Now once I have all of the above information, I need to create a vlib_buffer_t 
(possibly a chained set) So I need some guidelines/best practices of how to go 
about it flawlessly so that once the vlib_buffer_t is constructed, I can simply 
send it to the "interface-output" and accomplish the act of transmission.

The high level set of things that I can think of is --

1. Allocate a vlib_buffer_t (or a chained flavour of those) 2. Start appending 
data to those buffers 3. What about the various control fields to be set in the 
above buffers ?
. I suppose I will have to do the following --
  vnet_buffer (b0)->sw_if_index[VLIB_RX] = ;
vnet_buffer (b0)->sw_if_index[VLIB_TX] = ; Do I 
need to do anything with b0->buffer_pool_index ?
What to do with b0->current_data ?
What to do with b0->flags ?
What to do with b->current_length ?
And if it is a chained set, what is to be done on individual vlib_buffer_t of 
the chain and what on the first one of the chain ?

I suppose I need a convenience function like the following

vlib_buffer_t* foo(char* myl2packet, int lengthOfMyL2Packet, u32 mySwIfRxIndex, 
u32 mySwIfTxIndex)

The above should return to me a nice little vlib_buffer_t (possibly
chained) which I can then ship to interface output.
I am willing to write such a function by all means but want to find out if 
anything like this (or closer) already exists.
If it doesn't exist, what idioms can I follow from the functions which already 
exist and what I have to be careful about.

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

View/Reply Online (#11012): https://lists.fd.io/g/vpp-dev/message/11012
Mute This Topic: https://lists.fd.io/mt/27770677/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] How to save VPP configuration

[Dave Barach via Lists.Fd.Io]

Here’s one simple way to do it:

$ cat /etc/vpp/startup.conf
unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  startup-config /etc/setup.gate
  gid vpp
}




From: vpp-dev@lists.fd.io  On Behalf Of tianye@sina
Sent: Friday, October 26, 2018 6:29 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] How to save VPP configuration

Hello Everyone:

Almost all of the telecom devices could save the user configuration.
But in VPP, it’s look like when VPP process is restart, the previous 
configuration will missing.
For example, After I added a Vxlan Tunnel then restart the VPP process and log 
in to the VPP console.
Then re-run the “show interface” command, the Vxlan tunnel which I added last 
time is gone!

So, Is there someone who know how to save the configuration so that I could 
save my modification permanently?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10999): https://lists.fd.io/g/vpp-dev/message/10999
Mute This Topic: https://lists.fd.io/mt/27738030/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] VPP cores out of vl_client_connect()

[Dave Barach via Lists.Fd.Io]

“# rm /dev/shm/*” and try again. The shared VM arena is persistent.

From: vpp-dev@lists.fd.io  On Behalf Of siddarth rai
Sent: Thursday, October 25, 2018 8:44 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP cores out of vl_client_connect()

Hi all,
I am facing VPP crash from vl_client_connect . It continuously crashes when the 
client tries to reconnect.
I am using VPP version v18.01.1-100~g3a6948c.

Here is the backtrace:

Program terminated with signal 6, Aborted.
#0  0x2b0f894ff207 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install OPWVmepCR-99.9-el7.x86_64
(gdb) bt
#0  0x2b0f894ff207 in raise () from /lib64/libc.so.6
#1  0x2b0f895008f8 in abort () from /lib64/libc.so.6
#2  0x2b0f98c6c4a9 in os_panic () at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vppinfra/unix-misc.c:176
#3  0x2b0f98c6c4c5 in os_out_of_memory () at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vppinfra/unix-misc.c:221
#4  0x2b0f98e8fda5 in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=0, align=64, size=120120)
at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:105
#5  clib_mem_alloc_aligned (align=64, size=120120) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:122
#6  unix_shared_memory_queue_init (nels=nels@entry=15000, 
elsize=elsize@entry=8, consumer_pid=41923, 
signal_when_queue_non_empty=signal_when_queue_non_empty@entry=0)
at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/unix_shared_memory_queue.c:58
#7  0x2b0f98e8b7d8 in vl_client_connect (name=name@entry=0x10852658 
"opwv_ats_client-0x36d6000-0", ctx_quota=ctx_quota@entry=0, 
input_queue_size=input_queue_size@entry=15000, timeout=timeout@entry=10)
at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/memory_client.c:210
#8  0x2b0f992be17a in vapi_connect (ctx=0x1097c900, name=0x10852658 
"opwv_ats_client-0x36d6000-0", chroot_prefix=0x0, 
max_outstanding_requests=, response_queue_size=15000, 
mode=VAPI_MODE_NONBLOCKING,
timeout=10) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/third-party/vpp/vpp_1801/build-data/../src/vpp-api/vapi/vapi.c:347
#9  0x2b0f951e6fb5 in TUIOVpp::TUIOVpp (this=0x10978990, uio=, requestQueueSize=1, responseQueueSize=15000, master=)
at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/atsrequest/UIOVpp.cpp:87
#10 0x2b0f951cfc53 in TUIO::createInstance (this=this@entry=0x2b0f95423f20 
) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/atsrequest/UIO.cpp:632
#11 0x2b0f951d37af in TUIO::init (this=this@entry=0x2b0f95423f20 
) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/atsrequest/UIO.cpp:492
#12 0x2b0f951a92f4 in TATSRequest::init () at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/atsrequest/ATSRequest.cpp:266
#13 0x2b0f9d4aebeb in init_oam_and_spa (argv=, 
argc=) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/traffic_server/plugin.cpp:833
#14 TSPluginInit (argc=, argv=) at 
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-09-2333/http/src/traffic_server/plugin.cpp:972
#15 0x0050262b in plugin_load (internal=false, argv=0x7ffe36840900, 
argc=6) at Plugin.cc:166

Any help or pointers will be greatly appreciated.

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

View/Reply Online (#10986): https://lists.fd.io/g/vpp-dev/message/10986
Mute This Topic: https://lists.fd.io/mt/27631777/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] Memory Performance issue #vpp

[Dave Barach via Lists.Fd.Io]

There is no such thing as a free lunch.

If you force a fresh allocation measured in gigabytes, the memory allocator 
will mmap(...) a bunch of (4k) pages which will incur (expensive) pagefaults as 
they’re populated. Vec_validate(...) copies data when necessary. When 
structures grow to gigabytes, that takes a measurable amount of time and will 
almost certainly result in packet drops.

Preallocation is the only strategy for avoiding packet drops when data 
structures expand beyond a certain size. Either that, or simply accept 
vector-size excursions until vpp reaches steady state: at that point, data 
structures shouldn’t have to expand, and you shouldn’t drop any more packets.

Note that vec_reset_length(v) is highly preferable to constant cycling of fresh 
large vectors from vec_validate(...) / vec_add1(...) to vec_free(...).

HTH... D.


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, October 24, 2018 11:06 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Memory Performance issue #vpp


[Edited Message Follows]
Do you mean it is impossible to have packet processing and memory operation at 
the same time,
for example doing vec_validate or vec_free when NAT plugin is working and 
create new session.

I have drop rate when vec_free or vec_vlidate for memory size greater than 3GB.

What are your suggestions for such problems?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Memory Performance issue #vpp

[Dave Barach via Lists.Fd.Io]

“show memory” looks at every object in the heap, with packet processing 
disabled for the duration.

From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Wednesday, October 24, 2018 4:58 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Memory Performance issue #vpp

hi Matus

I know it will take some time when add new deterministic mapping.
But why "show memory" command has drop rate
Or why adding new deterministic mapping cause drop rate

Thanks !
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10954): https://lists.fd.io/g/vpp-dev/message/10954
Mute This Topic: https://lists.fd.io/mt/27615950/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
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_REGISTER_NODE

[Dave Barach via Lists.Fd.Io]

Use vlib_node_add_next(...) to create the graph arc at your convenience. 
Memorize the arc index when you create it, so you can set e.g. next0 to the 
correct value in MyNode.

HTH... Dave  

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Wednesday, October 24, 2018 2:15 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding VLIB_REGISTER_NODE

Hi,

I have a registered node like the following --

VLIB_REGISTER_NODE (MyNode) = {
.name = "MyNode",
.
.
.n_next_nodes =N,
.next_nodes = {
[firstone] = "error-drop",
[secondone] = "ip4-lookup",
[thirdone] = "ip6-lookup",
[fourthone] = "may-or-may-not-be-loaded-node",
.
.

Now I want to be able to run the system whether the fourth one above is loaded 
or not as a .so The business logic in my code takes care that I never use the 
fourth one in case it is not loaded. I have a private configuration which tells 
me whether the fourth one is present in deployment or not.

But the VLIB_REGISTER_NODE requires the wiring at compile time like the above.
And the system will not startup if the fourth one is not actually present in 
deployment

So I want to avoid mentioning the fourth one in the VLIB_REGISTER_NODE of 
MyNode as one of the next_nodes.
And then how to add it as one of the next_nodes from runtime for MyNode when my 
private configuration tells me that the fourthone indeed is existing in the 
deployment ? I am looking for some API to wink in the fourth one at runtime 
into .next_nodes of MyNode.

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

View/Reply Online (#10953): https://lists.fd.io/g/vpp-dev/message/10953
Mute This Topic: https://lists.fd.io/mt/27616631/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] VPP crashing out of dead_client_scan()

[Dave Barach via Lists.Fd.Io]

Read at face value, the vpp binary API memory segment (VA range 0x3000 and 
above) is out of memory. The failing allocation is a request for 60 bytes, 
which is not an unreasonable ask.

Before doing anything else, try increasing the size of the API segment and see 
if the problem recurs.

We do not support 18.01 at this point, but I’ll sketch the work necessary to 
track down a binary API segment memory leak in that code version.

It will take a certain amount of scaffolding work to track down binary API 
segment memory leaks. In src/vppinfra/mheap_bootstrap.h, set 
MHEAP_HAVE_SMALL_OBJECT_CACHE to 0 in all cases.

Patch the current “memory-trace” debug CLI command, and the current “show 
memory” command – see below. Boot vpp and enable memory tracing on the api 
segment.

Do whatever you normally do to cause the out-of-memory crash, but not for quite 
as long ()...

Then, “show memory api-segment” to look for API segment memory leaks.

Good luck.

Dave

static clib_error_t *
enable_disable_memory_trace (vlib_main_t * vm,
 unformat_input_t * input,
 vlib_cli_command_t * cmd)
{
  unformat_input_t _line_input, *line_input = &_line_input;
  int enable;
  int api_segment = 0;
  void *oldheap;


  if (!unformat_user (input, unformat_line_input, line_input))
return 0;

  while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT)
{
  if (unformat (line_input, "%U", unformat_vlib_enable_disable, ))
 ;
  else if (unformat (line_input, "api-segment"))
 api_segment = 1;
  else
 {
   unformat_free (line_input);
   return clib_error_return (0, "invalid input");
 }
}
  unformat_free (line_input);

  if (api_segment)
oldheap = vl_msg_push_heap ();
  clib_mem_trace (enable);
  if (api_segment)
vl_msg_pop_heap (oldheap);

  return 0;
}

/* *INDENT-OFF* */
VLIB_CLI_COMMAND (enable_disable_memory_trace_command, static) = {
  .path = "memory-trace",
  .short_help = "on|off [api-segment] Enable/disable memory allocation trace",
  .function = enable_disable_memory_trace,
};
/* *INDENT-ON* */


static clib_error_t *
show_memory_usage (vlib_main_t * vm,
  unformat_input_t * input, vlib_cli_command_t * cmd)
{
  int verbose __attribute__ ((unused)) = 0, api_segment = 0;
  clib_error_t *error;
  u32 index = 0;

  while (unformat_check_input (input) != UNFORMAT_END_OF_INPUT)
{
  if (unformat (input, "verbose"))
 verbose = 1;
  else if (unformat (input, "api-segment"))
 api_segment = 1;
  else
 {
   error = clib_error_return (0, "unknown input `%U'",
  format_unformat_error, input);
   return error;
 }
}

  if (api_segment)
{
  void *oldheap = vl_msg_push_heap ();
  u8 *s_in_svm =
 format (0, "%U\n", format_mheap, clib_mem_get_heap (), 1);
  vl_msg_pop_heap (oldheap);
  u8 *s = vec_dup (s_in_svm);

  oldheap = vl_msg_push_heap ();
  vec_free (s_in_svm);
  vl_msg_pop_heap (oldheap);
  vlib_cli_output (vm, "API segment start:");
  vlib_cli_output (vm, "%v", s);
  vlib_cli_output (vm, "API segment end:");
  vec_free (s);
}

#if USE_DLMALLOC == 0
  /* *INDENT-OFF* */
  foreach_vlib_main (
  ({
  mheap_t *h = mheap_header (clib_per_cpu_mheaps[index]);
  vlib_cli_output (vm, "%sThread %d %s\n", index ? "\n":"", index,
  vlib_worker_threads[index].name);
  vlib_cli_output (vm, "  %U\n", format_page_map, pointer_to_uword (h) -
 h->vm_alloc_offset_from_header,
  h->vm_alloc_size);
  vlib_cli_output (vm, "  %U\n", format_mheap, clib_per_cpu_mheaps[index],
   verbose);
  index++;
  }));
  /* *INDENT-ON* */
#else
  {
uword clib_mem_trace_enable_disable (uword enable);
uword was_enabled;

/*
 * Note: the foreach_vlib_main cause allocator traffic,
 * so shut off tracing before we go there...
 */
was_enabled = clib_mem_trace_enable_disable (0);

/* *INDENT-OFF* */
   foreach_vlib_main (
({
  struct dlmallinfo mi;
  void *mspace;
  mspace = clib_per_cpu_mheaps[index];

  mi = mspace_mallinfo (mspace);
  vlib_cli_output (vm, "%sThread %d %s\n", index ? "\n":"", index,
  vlib_worker_threads[index].name);
  vlib_cli_output (vm, "  %U\n", format_page_map,
   pointer_to_uword (mspace_least_addr(mspace)),
   mi.arena);
  vlib_cli_output (vm, "  %U\n", format_mheap, clib_per_cpu_mheaps[index],
   verbose);
  index++;
}));
/* *INDENT-ON* */

/* Restore the trace flag */
clib_mem_trace_enable_disable (was_enabled);
  }
#endif /* USE_DLMALLOC */
  return 0;
}

/* *INDENT-OFF* */
VLIB_CLI_COMMAND (show_memory_usage_command, static) = {
  .path = "show memory",
  .short_help = "[verbose | api-segment] Show current memory usage",
  .function = show_memory_usage,
};
/* 

Re: [vpp-dev] How translate some ctrl data to OS ?

[Dave Barach via Lists.Fd.Io]

See https://wiki.fd.io/view/VPP/VPP_Home_Gateway for a NAT-based example.

From: vpp-dev@lists.fd.io  On Behalf Of 
wangchuan...@163.com
Sent: Tuesday, October 23, 2018 2:55 AM
To: vpp-dev 
Subject: [vpp-dev] How translate some ctrl data to OS ?

Hi all，
PCA have running a VPP that have only 1 hw_if : GigabitEthernet2/0/0 , 1 
ip:172.16.0.2/16,   and already have vxlan [172.16.0.2 - 172.16.0.3].
How should I config the vpp to let me login the PCA'sOS from 172.16.0.4 by SSH ?

Is there some feature ? e.g. ip-port mapping







wangchuan...@163.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10917): https://lists.fd.io/g/vpp-dev/message/10917
Mute This Topic: https://lists.fd.io/mt/27566201/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] How are graph nodes scheduled?

[Dave Barach via Lists.Fd.Io]

See …/src/vlib/main.c, and 
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html?highlight=dispatch#graph-node-dispatcher
 

At this level, we need to make a distinction between a vlib_pending_frame_t – a 
vector of buffer indices to be processed by a certain node – and the nodes 
themselves.  Input nodes schedule pending frames – quite often, multiple 
pending frames. The dpdk plugin input routine will be perfectly happy to 
schedule a frame to be processed by ip4-input-no-checksum AND ip6-input in the 
same dispatch cycle.

Each worker thread / vlib_main_t has its own pending frame vector, which is the 
basic way the code processes multiple frames in parallel with multiple worker 
threads.

There are some corner-cases in the code base having to do with vpp’s directed 
(vs. directed *acyclic*) node graph. It’s normal for packets to “loop back” in 
the graph. Consider adding gre tunnel encaps, and handing the packets back to 
ip4-lookup. It’s OK (albeit really odd) for a node to enqueue packets back to 
itself.

HTH… Dave

On 10/21/18, 10:27 AM, "vpp-dev@lists.fd.io on behalf of A. Ilchinger" 
 wrote:

Hello,

I'd like to know a few more details how the packet scheduling in the
node graph works.
From what I understand, in every scheduling "event", the input node is
executed. But what about the other nodes? Are they executed in parallel
or sequentially? Is a packet vector processed completely after every
scheduling "event" or does it need multiple to get processed fully? Is
there always a single packet vector moving through the graph at the
same time or can there be multiple packet vectors?

Kind regards
Andreas


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

View/Reply Online (#10896): https://lists.fd.io/g/vpp-dev/message/10896
Mute This Topic: https://lists.fd.io/mt/27434714/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] VPP crash after days of heavy traffic, next_index is not associated to an interface #vpp_stability

[Dave Barach via Lists.Fd.Io]

Thanks for the report… This is the sort of thing we need to clean up. We do 
very little negative testing of the form: send the kitchen sink with nothing 
configured.

From:  on behalf of JB 
Date: Sunday, October 21, 2018 at 9:59 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] VPP crash after days of heavy traffic, next_index is not 
associated to an interface #vpp_stability


Hi Dave,



We have not configured LISP-GPE



Could it be that VPP received an encapsulated packet it wasn't expecting 
causing it to crash? That'd be dangerous



I'll have a look at the page for bug reports!

Thanks,
John
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Question about VPP plugin/node's life cycle

[Dave Barach via Lists.Fd.Io]

Dear Ray,

As you probably suspect: plugins are neither unloaded nor reloaded.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Rui Cai via 
Lists.Fd.Io
Sent: Thursday, October 18, 2018 9:43 PM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [SUSPICIOUS] [vpp-dev] Question about VPP plugin/node's life cycle

Hello vpp experts:

I'm trying to figure out a plugin/node's life cycle with in VPP process. There 
is very rich code/documentation talking about plugin 
registration/initialization and node registration. I understand that nodes are 
created during node graph build up and during plugin init function I can 
further manipulate the edges of my nodes. However, I'm having trouble finding 
the code that handles node tear down/plugin un-initialization. Does VPP have a 
notion of plugin/node un-initialization? For example, if my plugin allocated 
some object during init, I would expect to free it in un-init. If there is such 
concept, what should I search to find them? Or pretty much the node/plugin 
lives as long as the VPP process is running and the plugin/node life cycle is 
never going to be shorter than VPP process?

Thanks a lot!
-Ray
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10877): https://lists.fd.io/g/vpp-dev/message/10877
Mute This Topic: https://lists.fd.io/mt/27411530/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] Unable to build router plugin

[Dave Barach via Lists.Fd.Io]

#include  and try again?

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of carlito nueno
Sent: Wednesday, October 17, 2018 11:16 PM
To: hongjun...@intel.com
Cc: Mehran Memarnejad ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Unable to build router plugin

Hi Hongjun,

Thanks for the patch.
I tried to compile VPPSB project with the latest master and latest VPP
stable/1810 but I am getting this error:

 Building router in /vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject.lo
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
  CC   router/tap_inject_tap.lo
/vpp/build-data/../router/router/tap_inject_node.c: In function
‘tap_inject_tap_send_buffer’:
/vpp/build-data/../router/router/tap_inject_node.c:45:13: error:
implicit declaration of function ‘writev’; did you mean ‘write’?
[-Werror=implicit-function-declaration]
   n_bytes = writev (fd, , 1);
 ^~
 write
/vpp/build-data/../router/router/tap_inject_node.c: In function ‘tap_rx’:
/vpp/build-data/../router/router/tap_inject_node.c:231:13: error:
implicit declaration of function ‘readv’; did you mean ‘read’?
[-Werror=implicit-function-declaration]
   n_bytes = readv (fd, iov, MTU_BUFFERS);
 ^
 read
cc1: all warnings being treated as errors
Makefile:483: recipe for target 'router/tap_inject_node.lo' failed
make[1]: *** [router/tap_inject_node.lo] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
Makefile:691: recipe for target 'router-build' failed
make: *** [router-build] Error 2

Thanks
On Sun, Oct 7, 2018 at 7:25 PM Ni, Hongjun  wrote:
>
> Hi guys,
>
> I have submitted a patch to fix the build issue in VPPSB project:
> https://gerrit.fd.io/r/#/c/15135/ Fix build issue due to vpp's 
> function parameters change I have tested it and it works well in my server.
>
> Thanks,
> Hongjun
>
> -Original Message-
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
> carlito nueno
> Sent: Friday, September 28, 2018 9:45 AM
> To: memarnejad...@gmail.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Unable to build router plugin
>
> Thanks for the tip Mehran. I will take a look and report back.
> On Thu, Sep 27, 2018 at 12:16 AM Mehran Memarnejad  
> wrote:
> >
> > Hi carlito,
> >
> > I've had problems muck like yours. Sometimes VPP updates its functions 
> > while vppsb is still the same, so you need to change it to make it work.
> > In my problem I just updated the vppsb's outdated function to the new one 
> > and it worked.
> > As you know, vppsb is a plugin for vpp and it calls vpp's functions, 
> > so any change in vpp's function affects vppsb e.g. function 
> > singnature change
> >
> >
> > On Thursday, September 27, 2018, carlito nueno  
> > wrote:
> >>
> >> Hi all,
> >>
> >> I am trying to build the router-plugin:
> >> make V=0 PLATFORM=vpp TAG=vpp_debug install-deb netlink-install 
> >> router-install
> >>
> >> I am using the Vagrantfile present in vpp repo and am pulling the 
> >> current master (as of September 26 2018). I am also pulling the 
> >> current master of vppsb.
> >>
> >> But I am getting this error:
> >>
> >>  Building router in 
> >> /vpp/build-root/build-vpp_debug-native/router
> >> 
> >> make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
> >>   CC   router/tap_inject.lo
> >>   CC   router/tap_inject_netlink.lo
> >> /vpp/build-data/../router/router/tap_inject_netlink.c: In function
> >> ‘add_del_neigh’:
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:140:9: error:
> >> too many arguments to function ‘vnet_unset_ip6_ethernet_neighbor’
> >>  vnet_unset_ip6_ethernet_neighbor (vm, sw_if_index,
> >>  ^~~~ In file included from
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:19:0:
> >> /vpp/build-root/install-vpp_debug-native/vpp/include/vnet/ip/ip6_neighbor.h:84:12:
> >> note: declared here
> >>  extern int vnet_unset_ip6_ethernet_neighbor (vlib_main_t * vm,
> >> ^~~~
> >> Makefile:483: recipe for target 'router/tap_inject_netlink.lo' 
> >> failed
> >> make[1]: *** [router/tap_inject_netlink.lo] Error 1
> >> make[1]: *** Waiting for unfinished jobs
> >> make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
> >> Makefile:691: recipe for target 'router-build' failed
> >> make: *** [router-build] Error 2
> >>
> >> Any advice?
> >>
> >> Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10867): https://lists.fd.io/g/vpp-dev/message/10867
Mute This Topic: https://lists.fd.io/mt/26280661/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] Elog binary file format

[Dave Barach via Lists.Fd.Io]

There’s no reason to economize when sizing the main heap for a vppinfra 
application. It’s virtual memory, only pages which are in use are backed by 
physical pages, etc.

From:  on behalf of Aleksander Djuric 

Date: Wednesday, October 10, 2018 at 3:29 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Elog binary file format

Hi Florin,

Thank you very much! It works now.

1) Why you use such big memory size value (256 << 20) in 
clib_mem_init_thread_safe ?
Maybe we must to calculate the required size?
sizeof(elog_main_t) + elog_file_size ?

2) I've calculate start time of a log from init_time:
elog_main_t *em = _main;
st = em->init_time.os_nsec / 1e9 + 1490885108;
Is it correct?

Aleksander 


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

View/Reply Online (#10792): https://lists.fd.io/g/vpp-dev/message/10792
Mute This Topic: https://lists.fd.io/mt/26875131/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] Query regarding cli function handler

[Dave Barach via Lists.Fd.Io]

Debug CLI commands are executed in “process” [aka cooperating multitasking 
thread] context. As such, the stack has a fixed maximum size of 65K. See 
…/src/vlib/unix/cli.c, search for “.process_log2_n_stack_bytes = 16”…

HTH… Dave

From:  on behalf of Alok Makhariya 

Date: Tuesday, October 9, 2018 at 3:18 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Query regarding cli function handler


I am writing cli handler.
Is there any stack limit for cli function handler ?
What will happen if I define a large local variable inside function handler ?

Thanks
Alok

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

View/Reply Online (#10778): https://lists.fd.io/g/vpp-dev/message/10778
Mute This Topic: https://lists.fd.io/mt/27120391/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] Tx packet drops - dpdk tx failure

[Dave Barach via Lists.Fd.Io]

Note the vector size. Vpp isn’t even working hard enough to run efficiently. 
The tx side of the interface you’re using appears to be throttled.

D.

From: Santosh Kumar Dornal 
Sent: Friday, October 5, 2018 6:30 PM
To: j...@netgate.com
Cc: vpp-dev@lists.fd.io; Dave Barach (dbarach) 
Subject: Re: [vpp-dev] Tx packet drops - dpdk tx failure


Hi Dave

Here is the output of "show run". I am using Trex tool and generating 1500 byte 
udp packets.

vpp# show errors
   CountNode  Reason
16arp-input   ARP replies sent
 15611 VirtualFunctionEthernet0/7/0-txTx packet drops (dpdk tx 
failure)
vpp#
vpp# show runtime
Time 30.5, average vectors/node 2.34, last 128 main loops 0.00 per node 0.00
  vector rates in 3.4424e5, out 3.4373e5, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
VirtualFunctionEthernet0/6/0-o   active  1   1  
 0  8.02e21.00
VirtualFunctionEthernet0/6/0-t   active  1   1  
 0  3.83e31.00
VirtualFunctionEthernet0/7/0-o   active448307810493156  
 0  7.35e12.34
VirtualFunctionEthernet0/7/0-t   active448307810477545  
 0  3.11e22.34
api-rx-from-ringany wait 0   0  
 1  1.02e40.00
arp-inputactive  1   2  
 0  2.03e42.00
dhcp-client-process any wait 0   0  
 1  3.77e30.00
dpdk-input   polling 21841007510493157  
 0  5.23e3 .05
dpdk-processany wait 0   0  
10  9.76e40.00
ethernet-input   active  1   2  
 0  2.86e32.00
fib-walkany wait 0   0  
15  5.84e30.00
ikev2-manager-process   any wait 0   0  
31  2.86e30.00
interface-output active  1   2  
 0  2.51e32.00
ip-route-resolver-process   any wait 0   0  
 1  3.60e30.00
ip4-inputactive448307810493155  
 0  1.45e22.34
ip4-lookup   active448307810493155  
 0  9.87e12.34
ip4-reassembly-expire-walk  any wait 0   0  
 3  5.86e30.00
ip4-rewrite  active448307810493155  
 0  8.12e12.34
ip6-icmp-neighbor-discovery-ev  any wait 0   0  
31  2.71e30.00
ip6-reassembly-expire-walk  any wait 0   0  
 3  5.53e30.00
lisp-retry-service  any wait 0   0  
15  6.00e30.00
rd-cp-process   any wait 0   0  
   1514830  3.02e20.00
unix-cli-local:6 active  0   0  
97  1.59e50.00
unix-epoll-input polling213083   0  
 0  1.11e30.00
vpe-oam-process any wait 0   0  
15  3.99e30.00
vpp#

--
Santosh


On Fri, Oct 5, 2018 at 7:29 AM Jim Thompson 
mailto:j...@netgate.com>> wrote:

We’ve seen 4.6Gbps IPsec on a single core of a C5 instance, and that’s 
throttled by the 5gbps in and out of the VPC “limit” courtesy of Amazon.  (The 
other 400Mbps is framing overhead.)
But here, obviously, “large packets” (we were using iperf3 on the tunnel).

Jim


On Oct 5, 2018, at 6:38 AM, Dave Barach via Lists.Fd.Io<http://Lists.Fd.Io> 
mailto:dbarach=cisco@lists.fd.io>> wrote:

I’ll let others jump in on the tx [and rx] drops. At some level, it looks the 
vfio device simply isn’t disposing of traffic rapidly enough. Perhaps too few 
buffers have been configured, but I don’t think that’s the most likely 
explanation.

The “show run” stats are not helpful because they include over 2000 seconds’s 
worth of [mostly] dead airtime: please start traffic, “clear run”, wait a few 
seconds, 

Re: [vpp-dev] Tx packet drops - dpdk tx failure

[Dave Barach via Lists.Fd.Io]

I’ll let others jump in on the tx [and rx] drops. At some level, it looks the 
vfio device simply isn’t disposing of traffic rapidly enough. Perhaps too few 
buffers have been configured, but I don’t think that’s the most likely 
explanation.

The “show run” stats are not helpful because they include over 2000 seconds’s 
worth of [mostly] dead airtime: please start traffic, “clear run”, wait a few 
seconds, then “show run”.

You didn’t mention the packet size that you’re using. It wouldn’t shock me to 
learn that a “10xGE capable instance” comes with a few stars in the margin: 
perhaps “10xGE capable at or above 256 byte packets” or some such.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Santosh Kumar 
Dornal
Sent: Thursday, October 4, 2018 9:40 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Tx packet drops - dpdk tx failure

Hi

I am using VPP 18.04 on AWS (c5.xlarge instance with ena interfaces) and 
running into Tx packet drops when pushing traffic over 2.5Gbps (bidirectional). 
The instance is capable of doing 10gig. Can somebody help?

vpp# show version
vpp v18.04-16~gca7a68e0 built by vagrant on debian9.localdomain at Wed Oct  3 
11:57:44 PDT 2018
vpp# show errors
   CountNode  Reason
68arp-input   ARP replies sent
  82693102 VirtualFunctionEthernet0/6/0-txTx packet drops (dpdk tx 
failure)
  83200033 VirtualFunctionEthernet0/7/0-txTx packet drops (dpdk tx 
failure)
vpp#

vpp# show hardware-interfaces  detail
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/6/0   1 up   VirtualFunctionEthernet0/6/0
  Ethernet address 02:d2:6c:6e:b0:1c
  AWS ENA VF
carrier up full duplex speed 1 mtu 9216
pci id:device 1d0f:ec20 subsystem :
pci address:   :00:06.00
max rx packet len: 9216
max num of queues: rx 8 tx 8
promiscuous:   unicast off all-multicast off
vlan offload:  strip off filter off qinq off
rx offload caps:
tx offload caps:   ipv4-cksum udp-cksum tcp-cksum
rss active:ipv4-sctp ipv4-other ipv6-udp-ex ipv6-frag ipv6-tcp
   l2-payload
rss supported: none
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
cpu socket 0

tx frames ok   379327687
tx bytes ok 573877720248
rx frames ok   481696392
rx bytes ok 729288200634
rx missed 576271
extended stats:
  rx good packets  481696392
  tx good packets  379327687
  rx good bytes 729288200634
  tx good bytes 573877720248
  rx missed errors576271
  rx errors0
  tx errors0
  rx mbuf allocation errors0
  rx q0packets 0
  rx q0bytes   0
  rx q0errors  0
  tx q0packets 0
  tx q0bytes   0
VirtualFunctionEthernet0/7/0   2 up   VirtualFunctionEthernet0/7/0
  Ethernet address 02:cb:fc:e1:b2:e6
  AWS ENA VF
carrier up full duplex speed 1 mtu 9216
pci id:device 1d0f:ec20 subsystem :
pci address:   :00:07.00
max rx packet len: 9216
max num of queues: rx 8 tx 8
promiscuous:   unicast off all-multicast off
vlan offload:  strip off filter off qinq off
rx offload caps:
tx offload caps:   ipv4-cksum udp-cksum tcp-cksum
rss active:ipv4-sctp ipv4-other ipv6-udp-ex ipv6-frag ipv6-tcp
   l2-payload
rss supported: none
rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
cpu socket 0

tx frames ok   378158827
tx bytes ok 572532333080
rx frames ok   483669396
rx bytes ok 731851064762
rx missed 576803
extended stats:
  rx good packets  483669396
  tx good packets  378158827
  rx good bytes 731851064762
  tx good bytes 572532333080
  rx missed errors576803
  rx errors0
  tx errors0
  rx mbuf allocation errors0
  rx q0packets

Re: [vpp-dev] WRED

[Dave Barach via Lists.Fd.Io]

No luck reproducing the problem w/ multiple threads and 20 MPPS worth of 
traffic. The code involved doesn’t look trivially broken.

You might try setting a breakpoint in nsim_configure(...) and walk through it 
when you try to reconfigure the simulator with traffic flowing. I suppose an 
munmap accident might be involved, but I don’t see the problem.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, October 3, 2018 6:10 PM
To: Brendan Kelly 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] WRED

OK, let me see if I can repro it...

From: Brendan Kelly mailto:brendanake...@yahoo.com>>
Sent: Wednesday, October 3, 2018 6:03 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] WRED

This is what I gathered.  I need to figure out how to get on Jira.

vpp# show version verbose
Version:  v18.10-rc0~553-g2f54c27
Compiled by:  root
Compile host: o2.opiehome.com
Compile date: Tue Oct  2 16:58:15 MDT 2018
Compile location: /root/source/vpp/vpp
Compiler: GCC 7.3.1 20180303 (Red Hat 7.3.1-5)
Current PID:  5871
vpp# create bridge-domain 1
bridge-domain 1
vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet82/0/0  1 down 9000/0/0/0
TenGigabitEthernet82/0/1  2 down 9000/0/0/0
local00 down  0/0/0/0
vpp# set interface state TenGigabitEthernet82/0/0 up
vpp# set interface state TenGigabitEthernet82/0/1 up
vpp# set interface l2 bridge TenGigabitEthernet82/0/0 1
vpp# set interface l2 bridge TenGigabitEthernet82/0/1 1
vpp# set nsim delay 10 ms bandwidth 10.1 gbit packet-size 128
Configured link delay 10.00 ms, 20.00 ms round-trip
Sim uses 26304512 bytes per thread, 157827072 bytes total
vpp# nsim enable-disable TenGigabitEthernet82/0/0 TenGigabitEthernet82/0/1
vpp# show nsim
Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1
...inserting link delay of 10.00 ms, 20.00 ms round-trip
vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet82/0/0  1  up  9000/0/0/0 rx packets  
   16299
rx bytes
20247116
tx packets  
   23927
tx bytes
22969807
drops   
2407
TenGigabitEthernet82/0/1  2  up  9000/0/0/0 rx packets  
   23946
rx bytes
22972583
tx packets  
   16239
tx bytes
20206975
drops   
3549
local00 down  0/0/0/0
vpp# set nsim delay 50 ms bandwidth 10.1 gbit packet-size 128

Program received signal SIGSEGV, Segmentation fault.
_dl_fixup (l=0x6df680, reloc_arg=28) at ../elf/dl-runtime.c:71
71   const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
(gdb)


On Wednesday, October 3, 2018, 8:48:01 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:



Please send a backtrace. Here are some general bug reporting suggestions: 
https://wiki.fd.io/view/VPP/BugReports.



I’ve certainly reconfigured the simulator with traffic flowing without having 
the wheels fall off, but the code is brand-new.



Thanks... Dave





From: Brendan Kelly mailto:brendanake...@yahoo.com>>
Sent: Wednesday, October 3, 2018 10:39 AM
To: brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>
Cc: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] WRED



Hello Dave, if you change the nsim delay values on the fly it appears vpp 
crashes and all the state is lost.



Is this supported?  Should I file a bug?

If so what logs should I attach?

On Oct 3, 2018, at 08:07, Brendan Kelly via Lists.Fd.Io 
mailto:brendanakelly=yahoo@lists.fd.io>>
 wrote:

Ok, thanks for the input.  I have it working.



vpp# create bridge-domain 1

bridge-domain 1

vpp# show b

bfdbier   bond   bridge-domain  buffers

vpp# show bridge-domain 1

  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Floodi

Re: [vpp-dev] WRED

[Dave Barach via Lists.Fd.Io]

OK, let me see if I can repro it...

From: Brendan Kelly 
Sent: Wednesday, October 3, 2018 6:03 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] WRED

This is what I gathered.  I need to figure out how to get on Jira.

vpp# show version verbose
Version:  v18.10-rc0~553-g2f54c27
Compiled by:  root
Compile host: o2.opiehome.com
Compile date: Tue Oct  2 16:58:15 MDT 2018
Compile location: /root/source/vpp/vpp
Compiler: GCC 7.3.1 20180303 (Red Hat 7.3.1-5)
Current PID:  5871
vpp# create bridge-domain 1
bridge-domain 1
vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet82/0/0  1 down 9000/0/0/0
TenGigabitEthernet82/0/1  2 down 9000/0/0/0
local00 down  0/0/0/0
vpp# set interface state TenGigabitEthernet82/0/0 up
vpp# set interface state TenGigabitEthernet82/0/1 up
vpp# set interface l2 bridge TenGigabitEthernet82/0/0 1
vpp# set interface l2 bridge TenGigabitEthernet82/0/1 1
vpp# set nsim delay 10 ms bandwidth 10.1 gbit packet-size 128
Configured link delay 10.00 ms, 20.00 ms round-trip
Sim uses 26304512 bytes per thread, 157827072 bytes total
vpp# nsim enable-disable TenGigabitEthernet82/0/0 TenGigabitEthernet82/0/1
vpp# show nsim
Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1
...inserting link delay of 10.00 ms, 20.00 ms round-trip
vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet82/0/0  1  up  9000/0/0/0 rx packets  
   16299
rx bytes
20247116
tx packets  
   23927
tx bytes
22969807
drops   
2407
TenGigabitEthernet82/0/1  2  up  9000/0/0/0 rx packets  
   23946
rx bytes
22972583
tx packets  
   16239
tx bytes
20206975
drops   
3549
local00 down  0/0/0/0
vpp# set nsim delay 50 ms bandwidth 10.1 gbit packet-size 128

Program received signal SIGSEGV, Segmentation fault.
_dl_fixup (l=0x6df680, reloc_arg=28) at ../elf/dl-runtime.c:71
71   const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
(gdb)


On Wednesday, October 3, 2018, 8:48:01 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:



Please send a backtrace. Here are some general bug reporting suggestions: 
https://wiki.fd.io/view/VPP/BugReports.



I’ve certainly reconfigured the simulator with traffic flowing without having 
the wheels fall off, but the code is brand-new.



Thanks... Dave





From: Brendan Kelly mailto:brendanake...@yahoo.com>>
Sent: Wednesday, October 3, 2018 10:39 AM
To: brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>
Cc: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] WRED



Hello Dave, if you change the nsim delay values on the fly it appears vpp 
crashes and all the state is lost.



Is this supported?  Should I file a bug?

If so what logs should I attach?

On Oct 3, 2018, at 08:07, Brendan Kelly via Lists.Fd.Io 
mailto:brendanakelly=yahoo@lists.fd.io>>
 wrote:

Ok, thanks for the input.  I have it working.



vpp# create bridge-domain 1

bridge-domain 1

vpp# show b

bfdbier   bond   bridge-domain  buffers

vpp# show bridge-domain 1

  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Flooding  
ARP-Term   BVI-Intf

1   1  0 offonon   floodon   
offN/A



vpp# set interface l2 bridge TenGigabitEthernet82/0/0 1

vpp# set interface l2 bridge TenGigabitEthernet82/0/1 1



vpp# set nsim delay 10 ms bandwidth 10.1 gbit packet-size 128

Configured link delay 10.00 ms, 20.00 ms round-trip

Sim uses 26304512 bytes per thread, 157827072 bytes total



vpp# nsim enable-disable TenGigabitEthernet82/0/0 TenGigabitEthernet82/0/1



vpp# show nsim

Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1

...inserting link delay of 10.00 ms, 20.00 ms round-trip





On Wednesday, O

Re: [vpp-dev] WRED

[Dave Barach via Lists.Fd.Io]

Please send a backtrace. Here are some general bug reporting suggestions: 
https://wiki.fd.io/view/VPP/BugReports.

I’ve certainly reconfigured the simulator with traffic flowing without having 
the wheels fall off, but the code is brand-new.

Thanks... Dave


From: Brendan Kelly 
Sent: Wednesday, October 3, 2018 10:39 AM
To: brendanake...@yahoo.com
Cc: Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] WRED

Hello Dave, if you change the nsim delay values on the fly it appears vpp 
crashes and all the state is lost.

Is this supported?  Should I file a bug?
If so what logs should I attach?

On Oct 3, 2018, at 08:07, Brendan Kelly via Lists.Fd.Io 
mailto:brendanakelly=yahoo@lists.fd.io>>
 wrote:
Ok, thanks for the input.  I have it working.

vpp# create bridge-domain 1
bridge-domain 1
vpp# show b
bfdbier   bond   bridge-domain  buffers
vpp# show bridge-domain 1
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Flooding  
ARP-Term   BVI-Intf
1   1  0 offonon   floodon   
offN/A

vpp# set interface l2 bridge TenGigabitEthernet82/0/0 1
vpp# set interface l2 bridge TenGigabitEthernet82/0/1 1

vpp# set nsim delay 10 ms bandwidth 10.1 gbit packet-size 128
Configured link delay 10.00 ms, 20.00 ms round-trip
Sim uses 26304512 bytes per thread, 157827072 bytes total

vpp# nsim enable-disable TenGigabitEthernet82/0/0 TenGigabitEthernet82/0/1

vpp# show nsim
Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1
...inserting link delay of 10.00 ms, 20.00 ms round-trip


On Wednesday, October 3, 2018, 7:19:00 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:



It would be easy enough for the delay simulator to enable/disable promiscuous 
mode. But it’s handy to bridge the pipes: traffic flows whether or not the 
delay simulation is enabled.



D.



From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, October 3, 2018 9:09 AM
To: Brendan Kelly mailto:brendanake...@yahoo.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] WRED



Put the interfaces in an L2 bridge group, or they won’t be in promiscuous 
mode...



Here’s a config that I use a bunch:



set int l2 bridge FortyGigabitEthernet86/0/1 1

set int state FortyGigabitEthernet86/0/1 up

set int l2 bridge TenGigabitEthernetd/0/0 1

set int state TenGigabitEthernetd/0/0 up



bin nsim_configure delay 10 ms bandwidth 10.1 gbit packet-size 128

bin nsim_enable_disable FortyGigabitEthernet86/0/1 TenGigabitEthernetd/0/0



HTH... Dave



From: Brendan Kelly mailto:brendanake...@yahoo.com>>
Sent: Tuesday, October 2, 2018 10:03 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>
Subject: Re: [vpp-dev] WRED



Hello Dave, doesn't appear to forward.  My ARP packets are not being forwarded. 
 I assume in this cross connect any packet in an interface is sent out the 
other interface and vice versa?



Anything special needed in the startup.conf?



vpp# show nsim

Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1

...inserting link delay of 200.00 ms, 400.00 ms round-trip





On Tuesday, October 2, 2018, 6:00:42 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:





With respect to delay / loss impairments, please have a look at the “nsim” 
plugin: src/plugins/nsim.

From: mailto:vpp-dev@lists.fd.io>> on behalf of 
"brendanakelly via Lists.Fd.Io" 
mailto:yahoo@lists.fd.io>>
Reply-To: "brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>" 
mailto:brendanake...@yahoo.com>>
Date: Monday, October 1, 2018 at 6:18 PM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] WRED

I am looking to setup vpp with WRED.  I am not sure how the WRED profiles are 
configured.  I have hqos with 2 interfaces working in a bridge-domain and now 
want to enable WRED.

My overall goal is to simulate the Linux tc "traffic control" application to 
run impairments such as delay and packet loss.

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

View/Reply Online (#10730): https://lists.fd.io/g/vpp-dev/message/10730

Mute This Topic: https://lists.fd.io/mt/26596674/1432032
Group Owner: vpp-dev+ow...@lists.fd.io<mailto:ow...@lists.fd.io>
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
<https://lists.fd.io/g/vpp-dev/unsub%20> 
[brendanake...@yahoo.com<mailto:brendanake...@yahoo.com&

Re: [vpp-dev] WRED

[Dave Barach via Lists.Fd.Io]

It would be easy enough for the delay simulator to enable/disable promiscuous 
mode. But it’s handy to bridge the pipes: traffic flows whether or not the 
delay simulation is enabled.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, October 3, 2018 9:09 AM
To: Brendan Kelly ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] WRED

Put the interfaces in an L2 bridge group, or they won’t be in promiscuous 
mode...

Here’s a config that I use a bunch:

set int l2 bridge FortyGigabitEthernet86/0/1 1
set int state FortyGigabitEthernet86/0/1 up
set int l2 bridge TenGigabitEthernetd/0/0 1
set int state TenGigabitEthernetd/0/0 up

bin nsim_configure delay 10 ms bandwidth 10.1 gbit packet-size 128
bin nsim_enable_disable FortyGigabitEthernet86/0/1 TenGigabitEthernetd/0/0

HTH... Dave

From: Brendan Kelly mailto:brendanake...@yahoo.com>>
Sent: Tuesday, October 2, 2018 10:03 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>
Subject: Re: [vpp-dev] WRED

Hello Dave, doesn't appear to forward.  My ARP packets are not being forwarded. 
 I assume in this cross connect any packet in an interface is sent out the 
other interface and vice versa?

Anything special needed in the startup.conf?

vpp# show nsim
Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1
...inserting link delay of 200.00 ms, 400.00 ms round-trip


On Tuesday, October 2, 2018, 6:00:42 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:


With respect to delay / loss impairments, please have a look at the “nsim” 
plugin: src/plugins/nsim.

From: mailto:vpp-dev@lists.fd.io>> on behalf of 
"brendanakelly via Lists.Fd.Io" 
mailto:yahoo@lists.fd.io>>
Reply-To: "brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>" 
mailto:brendanake...@yahoo.com>>
Date: Monday, October 1, 2018 at 6:18 PM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] WRED

I am looking to setup vpp with WRED.  I am not sure how the WRED profiles are 
configured.  I have hqos with 2 interfaces working in a bridge-domain and now 
want to enable WRED.

My overall goal is to simulate the Linux tc "traffic control" application to 
run impairments such as delay and packet loss.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10730): https://lists.fd.io/g/vpp-dev/message/10730

Mute This Topic: https://lists.fd.io/mt/26596674/1432032
Group Owner: vpp-dev+ow...@lists.fd.io<mailto:ow...@lists.fd.io>
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
<https://lists.fd.io/g/vpp-dev/unsub%20> 
[brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10741): https://lists.fd.io/g/vpp-dev/message/10741
Mute This Topic: https://lists.fd.io/mt/26596674/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] WRED

[Dave Barach via Lists.Fd.Io]

Put the interfaces in an L2 bridge group, or they won’t be in promiscuous 
mode...

Here’s a config that I use a bunch:

set int l2 bridge FortyGigabitEthernet86/0/1 1
set int state FortyGigabitEthernet86/0/1 up
set int l2 bridge TenGigabitEthernetd/0/0 1
set int state TenGigabitEthernetd/0/0 up

bin nsim_configure delay 10 ms bandwidth 10.1 gbit packet-size 128
bin nsim_enable_disable FortyGigabitEthernet86/0/1 TenGigabitEthernetd/0/0

HTH... Dave

From: Brendan Kelly 
Sent: Tuesday, October 2, 2018 10:03 PM
To: vpp-dev@lists.fd.io; Dave Barach (dbarach) 
Subject: Re: [vpp-dev] WRED

Hello Dave, doesn't appear to forward.  My ARP packets are not being forwarded. 
 I assume in this cross connect any packet in an interface is sent out the 
other interface and vice versa?

Anything special needed in the startup.conf?

vpp# show nsim
Network simulator cross-connects TenGigabitEthernet82/0/0 and 
TenGigabitEthernet82/0/1
...inserting link delay of 200.00 ms, 400.00 ms round-trip


On Tuesday, October 2, 2018, 6:00:42 AM MDT, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:


With respect to delay / loss impairments, please have a look at the “nsim” 
plugin: src/plugins/nsim.

From: mailto:vpp-dev@lists.fd.io>> on behalf of 
"brendanakelly via Lists.Fd.Io" 
mailto:yahoo@lists.fd.io>>
Reply-To: "brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>" 
mailto:brendanake...@yahoo.com>>
Date: Monday, October 1, 2018 at 6:18 PM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] WRED

I am looking to setup vpp with WRED.  I am not sure how the WRED profiles are 
configured.  I have hqos with 2 interfaces working in a bridge-domain and now 
want to enable WRED.

My overall goal is to simulate the Linux tc "traffic control" application to 
run impairments such as delay and packet loss.

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

View/Reply Online (#10730): https://lists.fd.io/g/vpp-dev/message/10730

Mute This Topic: https://lists.fd.io/mt/26596674/1432032
Group Owner: vpp-dev+ow...@lists.fd.io<mailto:ow...@lists.fd.io>
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
<https://lists.fd.io/g/vpp-dev/unsub%20> 
[brendanake...@yahoo.com<mailto:brendanake...@yahoo.com>]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10740): https://lists.fd.io/g/vpp-dev/message/10740
Mute This Topic: https://lists.fd.io/mt/26596674/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] WRED

[Dave Barach via Lists.Fd.Io]

With respect to delay / loss impairments, please have a look at the “nsim” 
plugin: src/plugins/nsim.

From:  on behalf of "brendanakelly via Lists.Fd.Io" 

Reply-To: "brendanake...@yahoo.com" 
Date: Monday, October 1, 2018 at 6:18 PM
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] WRED

I am looking to setup vpp with WRED.  I am not sure how the WRED profiles are 
configured.  I have hqos with 2 interfaces working in a bridge-domain and now 
want to enable WRED.  

My overall goal is to simulate the Linux tc "traffic control" application to 
run impairments such as delay and packet loss. 


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

View/Reply Online (#10730): https://lists.fd.io/g/vpp-dev/message/10730
Mute This Topic: https://lists.fd.io/mt/26596674/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] Question about ip4(6)-glean node behavior and packet drops

[Dave Barach via Lists.Fd.Io]

IOS Classic, IOS XR, and NXOS behave slightly differently under the covers. To 
avoid disclosing trade secrets, I can’t go into the minutiae.

VPP uses buffers which hit glean adjacencies – e.g. an ip4 icmp echo request – 
to manufacture the outbound neighbor discovery packet (e.g. ip4 arp request).

D.

From: Burt Silverman 
Sent: Sunday, September 30, 2018 9:36 PM
To: Dave Barach (dbarach) 
Cc: ru...@microsoft.com; vpp-dev 
Subject: Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet 
drops

I read that a traditional Cisco CEF router behaves as follows:

"When the ping process tries to send the first packet and does not see an ARP 
entry, it initiates an ARP request. It continues to try to send the packet, and 
then drops the packet after a defined wait period. When an ARP response is 
received and the ARP entry is completed using a background process, the ping 
success rate is 100 percent."

Is that the same exact thing that happens with VPP? It is difficult for me to 
be certain. For example, it seems that if (in the traditional CEF router) the 
predefined wait period was set long enough (longer than the ARP processing 
time) then all the ping packets would be forwarded. That's not what they show 
in the text, though, at 
https://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/17812-cef-incomp.html#t4

Burt

On Fri, Sep 28, 2018 at 5:53 PM Dave Barach via Lists.Fd.Io<http://Lists.Fd.Io> 
mailto:cisco@lists.fd.io>> wrote:
This is deliberate, traditional router behavior.

Alternatives involving queueing packets for reinjection after glean resolution 
events give rise to resource exhaustion attacks. Mitigating that kind of attack 
burns clock cycles, which in turn gives rise to a different kind of attack.

HTH... Dave

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Rui Cai via 
Lists.Fd.Io<http://Lists.Fd.Io>
Sent: Friday, September 28, 2018 5:14 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [SUSPICIOUS] [vpp-dev] Question about ip4(6)-glean node behavior and 
packet drops

Hello VPP experts:

I have question about the behavior of ip4(6)-glean nodes. In particular, I’m 
noticing the node is dropping the original packet that triggered glean process. 
The VPP I’m running is 18.07 with DPDK 18.02.

I’m using VPP as a simple forwarding application where final destination’s MAC 
address is not known to VPP at the beginning. I’m sending IPv4 packet using 
scapy and for the 1st packet VPP receives, I see VPP redirects this packet to 
ip4-glean node where it will send an ARP request to learn forwarding 
destination’s MAC address. However, it appears the ip4-glean node will also 
drop my original packet that triggered this process. Is this an expected 
behavior?

If I keep deleting the arp entry of my final destination IP in VPP repeatedly 
(not that a normal application would keep doing this, but just for experiment), 
I see no packets reaching my final destination.

In general, is there some notion of “pending” packets in VPP? Like taking a 
packet out of current input vector and process such packet later, without 
blocking next input vectors getting generated?

Thanks a lot,
-Ray
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10711): https://lists.fd.io/g/vpp-dev/message/10711
Mute This Topic: https://lists.fd.io/mt/26380933/541103
Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev%2bow...@lists.fd.io>
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[bur...@gmail.com<mailto:bur...@gmail.com>]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10720): https://lists.fd.io/g/vpp-dev/message/10720
Mute This Topic: https://lists.fd.io/mt/26380933/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] Question about ip4(6)-glean node behavior and packet drops

[Dave Barach via Lists.Fd.Io]

This is deliberate, traditional router behavior.

Alternatives involving queueing packets for reinjection after glean resolution 
events give rise to resource exhaustion attacks. Mitigating that kind of attack 
burns clock cycles, which in turn gives rise to a different kind of attack.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Rui Cai via 
Lists.Fd.Io
Sent: Friday, September 28, 2018 5:14 PM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [SUSPICIOUS] [vpp-dev] Question about ip4(6)-glean node behavior and 
packet drops

Hello VPP experts:

I have question about the behavior of ip4(6)-glean nodes. In particular, I'm 
noticing the node is dropping the original packet that triggered glean process. 
The VPP I'm running is 18.07 with DPDK 18.02.

I'm using VPP as a simple forwarding application where final destination's MAC 
address is not known to VPP at the beginning. I'm sending IPv4 packet using 
scapy and for the 1st packet VPP receives, I see VPP redirects this packet to 
ip4-glean node where it will send an ARP request to learn forwarding 
destination's MAC address. However, it appears the ip4-glean node will also 
drop my original packet that triggered this process. Is this an expected 
behavior?

If I keep deleting the arp entry of my final destination IP in VPP repeatedly 
(not that a normal application would keep doing this, but just for experiment), 
I see no packets reaching my final destination.

In general, is there some notion of "pending" packets in VPP? Like taking a 
packet out of current input vector and process such packet later, without 
blocking next input vectors getting generated?

Thanks a lot,
-Ray
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10711): https://lists.fd.io/g/vpp-dev/message/10711
Mute This Topic: https://lists.fd.io/mt/26380933/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] DPDK pmd info

[Dave Barach via Lists.Fd.Io]

Just to ask: a supported (64-bit ()) PCI-ID table, that plus vendor strings, 
or something else? 

Makes sense but as Damjan wrote we're swamped right now. If you have time, go 
for it. Stick the results in the stats segment, maybe?

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Friday, September 28, 2018 11:22 AM
To: Stephen Hemminger 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] DPDK pmd info



> On 28 Sep 2018, at 12:13, Stephen Hemminger  
> wrote:
> 
> Having supported hardware list buried in DPDK plugin code is a nuisance. 
> Could the table be generated at build time maybe from pmdinfo or using dlopen 
> to lookup symbols?

Pure lack of manpower to cleanup this stuff.

Please note that we statically link dpdk libs so dlopen is not an option.

— 
Damjan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10707): https://lists.fd.io/g/vpp-dev/message/10707
Mute This Topic: https://lists.fd.io/mt/26375026/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] Skipping ipv4-input processing in L3Fwd

[Dave Barach via Lists.Fd.Io]

The only thing worth considering is to teach the ip4/6 input paths to skip work 
which the h/w and driver can do. As in: make a variant of ip4-input-no-checksum 
["ip4-input-no-checksum-no-ttl-no-fragment-no-"] by adding additional 
compile-time-constant arguments to the ip4-input inline and instantiating it.

Beyond that, Damjan is right: it's not a good idea, please don't go there.

HTH... Dave

-Original Message-
From: Damjan Marion  
Sent: Saturday, September 22, 2018 10:31 AM
To: Nitin Saxena 
Cc: Dave Barach (dbarach) ; vpp-dev 
Subject: Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd



— 
Damjan

> On 22 Sep 2018, at 16:10, Nitin Saxena  wrote:
> 
> Thanks Dave for the detailed answers.
> 
>> Patches which skip ANY of the work described above will not be merged.
> Understood. Intention is not to break functionality/security at all.
> 
>> You would have to pull a bunch of work back into the device driver: counting 
>> IP packet errors, head of ip4/6 unicast/multicast input feature arcs, and 
>> mandatory input checks (expired TTL, ip header length, fragment).
> Is it a confirmation that starting of "ip4/ip6 unicast/multicast" feature-arc 
> along with "device-input" feature arc in the “device_input” node itself is 
> acceptable by VPP?

No, it is not, ip4 packet may also go to l2 path.  You will end up with 
layering violation and bloatig driver code. Please dont go there.
> 
> I am also assuming that ipv4-lookup can be device-input’s next node, provided 
> stack functionalities/performance remains intact.

Ip4-input is also punt node, responsible for sending specific packets to the 
control plane. Iz should stay in the path...

> 
> Thanks,
> Nitin
> 
>> On 22-Sep-2018, at 6:12 PM, Dave Barach via Lists.Fd.Io 
>>  wrote:
>> 
>> External Email
>> 
>> You would have to pull a bunch of work back into the device driver: counting 
>> IP packet errors, head of ip4/6 unicast/multicast input feature arcs, and 
>> mandatory input checks (expired TTL, ip header length, fragment).
>> 
>> Hardware offload will NOT accomplish all of these tasks. If by chance you 
>> can convince it and/or the device driver to do SOME of these things - 
>> perhaps the ip header length, fragment, and expired TTL checks - variant 
>> ip4/6 input nodes can be constructed by working on ip4_input_inline(...) and 
>> ip6_input(...).
>> 
>> The rest of the forwarding graph - and by implication anyone running vpp - 
>> depend on these checks having been performed. These checks are important for 
>> three reasons: functional correctness, security, and observability.
>> 
>> Patches which skip ANY of the work described above will not be merged.
>> 
>> Thanks... Dave
>> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
>> Sent: Saturday, September 22, 2018 12:25 AM
>> To: vpp-dev 
>> Subject: [vpp-dev] Skipping ipv4-input processing in L3Fwd
>> 
>> Hi,
>> 
>> In case of L3Fwd, there is a possibility of handing of vlib_buffer from 
>> device-input to ipv4-lookup and thereby skipping 
>> ipv4-input/ipv4-input-no-chksum completely.
>> All ipv4-input/ipv4-input-nochksum functionalities can be offloaded to 
>> hardware and hence the node can be skipped.
>> 
>> Questions:
>> - If ipv4-input will be skipped is it fair to enable feature-arc in 
>> device-input node?
>> - Is it fair to add ipv4-lookup next node to device-input node?
>> 
>> Any other approach to be think about to leverage hardware offload 
>> functionalities?
>> 
>> Thanks,
>> Nitin
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#10608): https://lists.fd.io/g/vpp-dev/message/10608
>> Mute This Topic: https://lists.fd.io/mt/25907990/675748
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
>> [nsax...@caviumnetworks.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10609): https://lists.fd.io/g/vpp-dev/message/10609
> Mute This Topic: https://lists.fd.io/mt/25907990/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10611): https://lists.fd.io/g/vpp-dev/message/10611
Mute This Topic: https://lists.fd.io/mt/25907990/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] Skipping ipv4-input processing in L3Fwd

[Dave Barach via Lists.Fd.Io]

You would have to pull a bunch of work back into the device driver: counting IP 
packet errors, head of ip4/6 unicast/multicast input feature arcs, and 
mandatory input checks (expired TTL, ip header length, fragment).

Hardware offload will NOT accomplish all of these tasks. If by chance you can 
convince it and/or the device driver to do SOME of these things - perhaps the 
ip header length, fragment, and expired TTL checks - variant ip4/6 input nodes 
can be constructed by working on ip4_input_inline(...) and ip6_input(...).

The rest of the forwarding graph - and by implication anyone running vpp - 
depend on these checks having been performed. These checks are important for 
three reasons: functional correctness, security, and observability. 

Patches which skip ANY of the work described above will not be merged. 

Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
Sent: Saturday, September 22, 2018 12:25 AM
To: vpp-dev 
Subject: [vpp-dev] Skipping ipv4-input processing in L3Fwd

Hi,

In case of L3Fwd, there is a possibility of handing of vlib_buffer from 
device-input to ipv4-lookup and thereby skipping 
ipv4-input/ipv4-input-no-chksum completely.
All ipv4-input/ipv4-input-nochksum functionalities can be offloaded to hardware 
and hence the node can be skipped. 

Questions:
- If ipv4-input will be skipped is it fair to enable feature-arc in 
device-input node?
- Is it fair to add ipv4-lookup next node to device-input node? 

Any other approach to be think about to leverage hardware offload 
functionalities?

Thanks,
Nitin


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

View/Reply Online (#10608): https://lists.fd.io/g/vpp-dev/message/10608
Mute This Topic: https://lists.fd.io/mt/25907990/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] How vpp choose the default base va 0x130000000ULL

[Dave Barach via Lists.Fd.Io]

Any address above the first 4gb would be fine. At this point, it’s a bit like 
Avogadro’s number: when I see it, I know instantaneously which heap it came 
from.

If e.g. clib_mem_is_heap_object(...) ASSERTs on such an address, I know that 
some bit of code forgot “clib_mem_set_heap(...),” and so on.

D.


From: vpp-dev@lists.fd.io  On Behalf Of wylandrea
Sent: Friday, September 21, 2018 6:54 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] How vpp choose the default base va 0x13000ULL

Hi all,

In function svm_get_global_region_base_va it use the fixed addr 0x13000ULL, 
just curious why to choose that addr? why it's not another address, like 
0x23000ULL ?

Thanks!

/Yalei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10599): https://lists.fd.io/g/vpp-dev/message/10599
Mute This Topic: https://lists.fd.io/mt/25840997/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 pre_data field in vlib_buffer_t

[Dave Barach via Lists.Fd.Io]

+1. Note the vnet_buffer(b) and vnet_buffer2(b) macros. Track down the 
definitions in .../src/vlib/buffer.h and .../src/vnet/buffer.h and you'll 
understand how these opaque buffer metadata spaces are to be used.

Depending on where your graph nodes land, you must be careful not to smash 
metadata which will be used downstream.

Due to load-store unit pressure, (especially) vnet_buffer(b) fields are 
overlaid and have multiple uses. Any new use-case needs careful [manual] 
life-cycle analysis.

Example: if you set vnet_buffer(b)->sw_if_index[VLIB_TX] to a random number and 
ship that buffer to ip4/6-lookup, you'll get a nasty surprise.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Friday, September 21, 2018 6:36 AM
To: Prashant Upadhyaya 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding pre_data field in vlib_buffer_t


pre_data is not intended for that. It is headroom space which may be used
for outer headers in case of different tunnel encapsulation.

You can use opaque area in vlib_buffer_t

--
Damjan


On 21 Sep 2018, at 07:59, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi,

I want to pass around some custom data between my plugins using vlib_buffer_t.
I believe the pre_data field of 128 bytes can be used for this. (I use
the DPDK plugin)

However, are there some best practices to use this field ? I ask this
because I do see that some debug capabilities of VPP use this field
and if I start using this field then it might interfere with those
debug capabilties.

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

View/Reply Online (#10594): https://lists.fd.io/g/vpp-dev/message/10594
Mute This Topic: https://lists.fd.io/mt/25840898/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10598): https://lists.fd.io/g/vpp-dev/message/10598
Mute This Topic: https://lists.fd.io/mt/25840898/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] Increase in main core CPU usage between 17.10 and 18.04

[Dave Barach via Lists.Fd.Io]

At that PPS rate, you don't need two worker threads. The worker threads burn a 
bunch of cycles - poll-wait or not - doing next-to-nothing. Try running the 
main thread all by itself...

D.

-Original Message-
From: Heckman, Steve  
Sent: Tuesday, September 18, 2018 5:15 PM
To: Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: Increase in main core CPU usage between 17.10 and 18.04

We back-merged the unix poll wait timeout and a 100 usec delay gets us down to 
maybe 15%. Just wondering why the change originally.

top -H:

top - 17:09:45 up 19 days,  2:07,  7 users,  load average: 5.72, 5.85, 5.69
Threads: 491 total,   7 running, 484 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.9 us,  0.0 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.1 si,
0.0 st
KiB Mem : 26409392+total, 10683445+free, 15314609+used,  4113380 buff/cache
KiB Swap: 26830848+total, 26830848+free,0 used. 10981197+avail Mem

  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+
COMMAND 
 7621 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32
vpp_wk_0
 7622 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32
vpp_wk_1
 7615 root -51   0 11.789g 119608  17500 R 83.8  0.0  34:24.68
vpp_main  

sudo strace -p 7615:

epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0
epoll_pwait(5, [], 256, 0, [], 8)   = 0



Thread 0 vpp_main (lcore 16)
Time 2234.4, average vectors/node 1.07, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 1.6111e-2, drop 2.2377e-2, punt 0.e0
 Name State Calls 
VectorsSuspends Clocks   Vectors/Call 
TenGigabitEthernet5/0/0-output   active  3  
3   0  4.35e31.00
TenGigabitEthernet5/0/1-output   active 17 
17   0  3.45e31.00
TenGigabitEthernet8/0/0-output   active 18 
18   0  1.84e31.00
TenGigabitEthernet8/0/0-tx   active 18 
18   0  7.47e31.00
TenGigabitEthernet8/0/1-output   active 18 
18   0  1.62e31.00
TenGigabitEthernet8/0/1-tx   active 18 
18   0  6.92e31.00
acl-plugin-fa-cleaner-process  event wait0  
0   1  7.96e30.00
admin-up-down-process  event wait0  
0   1  1.70e30.00
api-rx-from-ringany wait 0  
0 119  7.05e40.00
avf-processevent wait0  
0   1  9.06e30.00
bfd-processevent wait0  
0   1  5.34e30.00
cdp-process any wait 0  
0   1  7.69e60.00
dhcp-client-process any wait 0  
0  23  7.64e30.00
dns-resolver-processany wait 0  
0   3  1.13e40.00
dpdk-ipsec-processdone   1  
0   0  7.18e40.00
dpdk-processany wait 0  
0 732  7.76e50.00
error-drop   active 45 
50   0  4.24e31.11
ethernet-input   active 16 
16   0  2.89e31.00
fib-walkany wait 0  
01097  2.19e30.00
flow-report-process any wait 0  
0   1  1.21e30.00
flowprobe-timer-process any wait 0  
0   1  6.17e30.00
icmp6-router-advertisement   active 15 
15   0  5.36e31.00
icmp6-router-solicitationactive 60 
73   0  4.19e31.22
igmp-timer-process event wait0  
0   1  8.86e30.00
ikev2-manager

Re: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04

[Dave Barach via Lists.Fd.Io]

"show run" please...

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of sheckman
Sent: Tuesday, September 18, 2018 4:58 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04


I've been seeing a dramatic increase in CPU usage by the vpp_main task.

It used to be around 0.3%.

Now it's around 85%.

I've pored over the release notes and design docs, but haven't found an 
explanation for this.

Why the increase?

Thanks,

Steve Heckman

Principal Software Engineer

Arris Group


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

View/Reply Online (#10547): https://lists.fd.io/g/vpp-dev/message/10547
Mute This Topic: https://lists.fd.io/mt/25750065/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] VPP's C-type-api example

[Dave Barach via Lists.Fd.Io]

The typical coding pattern to use when you don't know how many messages will 
come back: send a dump request, followed by an echo-ping.

When the ping reply shows up, the dump is complete...

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of 
wangchuan...@163.com
Sent: Tuesday, September 11, 2018 4:34 AM
To: vpp-dev 
Subject: [vpp-dev] VPP's C-type-api example

Hi all,
I code my example following src/vpp-api/client, but do {vac_read}while(1) 
often block when the results-num does not know.
It shows  
pthread_cond_wait
 when gdb.
Help please!
Thanks very much!

void printIntefaces()
{
  api_main_t * am = _main;
  vl_api_sw_interface_dump_t message;
  M_NOALLOC(SW_INTERFACE_DUMP);
  message.name_filter_valid = 0;
  strcpy(message.name_filter, "Gigabit");
  vac_write((char *), sizeof(message));
  char* pMsg = NULL;
  int nLen = 0;
  int ret = 0;
  int nCount = 0;
  do  {
printf("begin interface read .. \n");
ret = vac_read(, , 1);
printf("begin interface end .. \n");
if(ret != -1)
  {
vl_api_sw_interface_details_t* pSV = (vl_api_sw_interface_details_t*)pMsg;
printf("%lu:%s  \n", ntohl(pSV->sw_if_index), pSV->interface_name);
  vac_free(pMsg);
nCount += 1;
  }
else{
  break;
}
  }while(1);
 printf("get real count[%d] \n", nCount);
}


wangchuan...@163.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10467): https://lists.fd.io/g/vpp-dev/message/10467
Mute This Topic: https://lists.fd.io/mt/25510961/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] VPP main thread gets stuck in a deadlock on running CLI in loop

[Dave Barach via Lists.Fd.Io]

Please write up issues as described at: https://wiki.fd.io/view/VPP/BugReports. 
Without even a hint as to which version of vpp is involved, this report is not 
actionable.

Here’s an excerpt from the wiki page:


Although every situation is different, this page describes data which will help 
make efficient use of everyone's time when dealing with vpp bugs.

Before you press the Jira button to create a bug report - or email 
vpp-dev@lists.fd.io - please ask yourself whether there's enough information 
for someone else to understand and possibly to reproduce the issue given a 
reasonable amount of effort. Unicast emails to maintainers, committers, and the 
project PTL are strongly discouraged.

Unless, of course, you want to hear crickets.

From: vpp-dev@lists.fd.io  On Behalf Of siddarth rai
Sent: Saturday, September 8, 2018 11:02 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP main thread gets stuck in a deadlock on running CLI in 
loop

Hi,
I am running a script which fires a VPP CLI in loop and keeps collecting some 
data. The CLI hangs after sometimes and the main thread gets locked at 
"mheap_maybe_lock".

This is happening with other CLI commands as well.
Can anyone help? Also has anyone else observed this issue?

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

View/Reply Online (#10445): https://lists.fd.io/g/vpp-dev/message/10445
Mute This Topic: https://lists.fd.io/mt/25364321/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 when pressing TAB on CLI

[Dave Barach via Lists.Fd.Io]

In future, please refer to https://wiki.fd.io/view/VPP/BugReports. The issue 
you're reporting is not trivially reproducible.

At a minimum: we'll need a backtrace from a debug image, the vpp version 
string, the vpp startup config, and the connection method you used.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Liu Anhua
Sent: Wednesday, September 5, 2018 10:55 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] crash when pressing TAB on CLI

Hi,
I have a problem with the latest code. When I execute 'set interface ip' on the 
command line and press TAB, it will crash. The current direct reason is found 
in the qsort function. When comparing strings, the access is Illegal memory, 
the specific code is as follows:

for (min = base; (hi = min += q->qsz) < max;)
{
  while ((*q->qcmp) (hi -= q->qsz, min) > 0);
  if ((hi += q->qsz) != min)
   {
 for (lo = min + q->qsz; --lo >= min;)
   {
 c = *lo;
 for (i = j = lo; (j -= q->qsz) >= hi; i = j)
  *i = *j;
 *i = c;
   }
   }
}
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[FD.io Helpdesk #60548] [linuxfoundation.org #60548] FW: [vpp-dev] Suspicious login on fd.io wiki

[Dave Barach via RT]

Folks,

I've run into this annoyance myself. Attempting to authenticate to wiki.fd.io 
other than on the top-level page tends to produce "suspicious request, please 
try again" complaints.

This seems like a configuration error. Please either fix it, or explain why it 
cannot or should not be fixed.

Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Marco Varlese
Sent: Wednesday, September 5, 2018 9:31 AM
To: Vanessa Valderrama via RT 
Cc: vpp-dev@lists.fd.io; infra-steer...@lists.fd.io
Subject: [vpp-dev] Suspicious login on fd.io wiki

Hi,

I am not able to login to edit any page of the FD.io wiki. 

The error I get, by simply clicking on "Log in/Register..." is:
"suspicious request, please try again"

Can anybody take a look or suggest a workaround?


Cheers,
--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg


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

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

FW: [vpp-dev] Suspicious login on fd.io wiki

[Dave Barach via Lists.Fd.Io]

Folks,

I've run into this annoyance myself. Attempting to authenticate to wiki.fd.io 
other than on the top-level page tends to produce "suspicious request, please 
try again" complaints.

This seems like a configuration error. Please either fix it, or explain why it 
cannot or should not be fixed.

Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Marco Varlese
Sent: Wednesday, September 5, 2018 9:31 AM
To: Vanessa Valderrama via RT 
Cc: vpp-dev@lists.fd.io; infra-steer...@lists.fd.io
Subject: [vpp-dev] Suspicious login on fd.io wiki

Hi,

I am not able to login to edit any page of the FD.io wiki. 

The error I get, by simply clicking on "Log in/Register..." is:
"suspicious request, please try again"

Can anybody take a look or suggest a workaround?


Cheers,
--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

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

View/Reply Online (#10374): https://lists.fd.io/g/vpp-dev/message/10374
Mute This Topic: https://lists.fd.io/mt/25210631/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] vnet_feature_enable_disable disable option is broken

[Dave Barach via Lists.Fd.Io]

No, there isn’t. There isn’t much of a point in deleting graph arcs. If the 
feature is reenabled, the existing arc from A to B will be reused.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Tuesday, September 4, 2018 2:50 PM
To: .ılı.D'p@k.ılı. 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vnet_feature_enable_disable disable option is broken

Hi Deepak,

Not, as far as my quick code browse suggests.

—a

On 4 Sep 2018, at 20:25, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi Andrew,

Is there a similar delete call for the "vlib_node_add_next"  function?

Regards
Deepak Kumar Ch


On Tue, Sep 4, 2018 at 11:54 PM, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi Andrew,

I was expecting the delete command to remove acl from the ip4 arc and also the 
node graph of acl wont have ip4-lookup listed in its next nodes.
The current delete command is not doing a revert to old state.

Is there a way to make the node-graph go back to the init state?

Regards,
Deepak Kumar Ch








On Tue, Sep 4, 2018 at 10:46 PM, Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
Deepak,

If the feature enable/disable (or its usage) is broken, the trace for the 
traffic via thar interface with removed acl would still show the acl plugin 
node in the path, could you send the trace for a packet with acl and without 
acl to see whether it is the case ?

I don’t make any efforts to “nullify” the egress graph from the acl plugin 
nodes because 99% of the time after you remove the acl you will apply it back 
or apply a different acl, in my experience. Could you explain a bit more why 
you expect it differently ?

--a

On 4 Sep 2018, at 18:36, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi ,

When i remove acl from interface, its node graph doesnt revert back to original 
state.

#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]

//ADD ACl
vat# acl_add_replace ipv4 permit
vl_api_acl_add_replace_reply_t_handler:108: ACL index: 0

//ATTACH to interface
vat# acl_interface_add_del sw_if_index 2  add input acl 0

//CHECK if acl's vpp node graph has changed
#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]  ip4-mpls-label-disposition
ip4-lookup [1]  ip4-mpls-label-disposition
   ip4-input-no-checksum
 ip4-input

//DEL ACL
vat# acl_interface_add_del sw_if_index 2 del input acl 0

//CHECK if acl's vpp node graph has reverted back
#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]  ip4-mpls-label-disposition
ip4-lookup [1]  ip4-mpls-label-disposition
   ip4-input-no-checksum
 ip4-input

Regards,
Deepak Kumar Ch
--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10352): https://lists.fd.io/g/vpp-dev/message/10352
Mute This Topic: https://lists.fd.io/mt/25178343/675608
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[ayour...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-



--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey



--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10363): https://lists.fd.io/g/vpp-dev/message/10363
Mute This Topic: https://lists.fd.io/mt/25178343/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 in vpp 18.07

[Dave Barach via Lists.Fd.Io]

If possible, repeat the exercise with a debug image. The code involved is well 
tested, and does not crash without “help.” I wouldn’t be surprised to run into 
an ASSERT elsewhere which explains the problem.

For the specific packet in question: see if 
vnet_buffer(b)->sw_if_index[VLIB_TX] is set to a nonexistent FIB index. That’s 
one possible reason why the root mtrie ply might not play nicely with the other 
children.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of abbas ali chezgi 
via Lists.Fd.Io
Sent: Tuesday, August 28, 2018 5:16 AM
To: Vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] crash in vpp 18.07

more info after full core dump:


#0  0x7f57b1b6e428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f57b1b7002a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x5565b7348dee in os_exit (code=code@entry=1)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vpp/vnet/main.c:355
#3  0x7f57b3210035 in unix_signal_handler (signum=, 
si=,
uc=) at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/unix/main.c:157
#4  
#5  0x7f57b29b7321 in ip4_fib_mtrie_lookup_step_one 
(dst_address=0x7f576af32a1a, m=)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vnet/ip/ip4_mtrie.h:229
#6  ip4_local_check_src (error0=, last_check=,
ip0=0x7f576af32a0e, b=0x7f576af32900)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vnet/ip/ip4_forward.c:1280
#7  ip4_local_inline (head_of_feature_arc=1, frame=, 
node=,
vm=0x7f57b342cf80 )
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vnet/ip/ip4_forward.c:1514
#8  ip4_local (frame=, node=, vm=0x7f57b342cf80 
)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vnet/ip/ip4_forward.c:1534
#9  ip4_local_avx2 (vm=0x7f57b342cf80 , node=0x7f577155c3c0, 
frame=0x7f57721c4400)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vnet/ip/ip4_forward.c:1555
#10 0x7f57b31d63a4 in dispatch_node (last_time_stamp=85226775203136, 
frame=0x7f57721c4400,
dispatch_state=VLIB_NODE_STATE_POLLING, type=VLIB_NODE_TYPE_INTERNAL, 
node=0x7f577155c3c0,
vm=0x7f57b342cf80 )
at /w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/main.c:988
#11 dispatch_pending_node (vm=vm@entry=0x7f57b342cf80 ,
pending_frame_index=pending_frame_index@entry=5,
last_time_stamp=last_time_stamp@entry=85226775203136)
at /w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/main.c:1138
#12 0x7f57b31d7dee in vlib_main_or_worker_loop (is_main=1, 
vm=0x7f57b342cf80 )
at /w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/main.c:1616
#13 vlib_main_loop (vm=0x7f57b342cf80 )
at /w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/main.c:1635
#14 vlib_main (vm=vm@entry=0x7f57b342cf80 , 
input=input@entry=0x7f57717e4fa0)
at /w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/main.c:1826
#15 0x7f57b320f4d3 in thread0 (arg=140014646382464)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/unix/main.c:607
#16 0x7f57b234e778 in clib_calljmp ()
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vppinfra/longjmp.S:110
#17 0x7ffce83886c0 in ?? ()
#18 0x7f57b3210576 in vlib_unix_main (argc=, argv=)
at 
/w/workspace/vpp-merge-1807-ubuntu1604/build-data/../src/vlib/unix/main.c:674
#19 0x367063740038 in ?? ()
#20 0x502074657365722d in ?? ()
#21 0x64207374656b6361 in ?? ()
#22 0x6620646570706f72 in ?? ()
#23 0x206b63616c20726f in ?? ()
#24 0x696620787220666f in ?? ()
#25 0x6563617073206f66 in ?? ()
#26 0x6425203a in ?? ()
#27 0x in ?? ()


On Tuesday, August 28, 2018, 1:30:26 PM GMT+4:30, abbas ali chezgi via 
Lists.Fd.Io mailto:chezgi=yahoo@lists.fd.io>> 
wrote:



this crash accoured in vpp 18.07:

vpp[71]: received signal SIGSEGV, PC 0x7f125c775321, faulting address 
0x7f16ae006978
vpp[71]: #0  0x7f125cfcdf7f 0x7f125cfcdf7f
vpp[71]: #1  0x7f125bed6390 0x7f125bed6390
vpp[71]: #2  0x7f125c775321 ip4_local_avx2 + 0x905
vpp[71]: #3  0x7f125cf943a4 0x7f125cf943a4
vpp[71]: #4  0x7f125cf95dee vlib_main + 0x71e
vpp[71]: #5  0x7f125cfcd4d3 0x7f125cfcd4d3
vpp[71]: #6  0x7f125c10c778 0x7f125c10c778



running options:

unix {
log /outDir/vpp.log
cli-listen /run/vpp/cli.sock
}


api-segment {
prefix vpp1
}


plugins {
plugin default { enable }
plugin dpdk_plugin.so { disable }
}






thanks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10311): https://lists.fd.io/g/vpp-dev/message/10311
Mute This Topic: https://lists.fd.io/mt/25038079/1239119
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
 
[che...@yahoo.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to 

Re: [vpp-dev] received signal SIGSEGV and vpp restarts continuously

[Dave Barach via Lists.Fd.Io]

Cool... Please let us know if you run into trouble...

Thanks... Dave

-Original Message-
From: Carlito Nueno  
Sent: Monday, August 27, 2018 4:09 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] received signal SIGSEGV and vpp restarts continuously

Hi Dave,

I recompiled vpp v18.10-rc0~229-g869031c5 using master on 08-23-18 and have 
been running it since. I ran a few tests with various loads and it hasn't crash 
so far. So, I guess it was some kind of mistake on my part.

I will report back if anything changes.

Thank you.
On Thu, Aug 23, 2018 at 5:36 AM Dave Barach (dbarach)  wrote:
>
> Looks like a  NULL pointer - please decode the pc. It would help if you could 
> repro the problem with a debug image and send a full backtrace.
>
> vnet[10192]: received signal SIGSEGV, PC 0x7fa62aecade3, faulting 
> address 0x0
>
> D.
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of carlito 
> nueno
> Sent: Wednesday, August 22, 2018 4:07 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] received signal SIGSEGV and vpp restarts 
> continuously
>
> Hi all,
>
> I am using vpp 18.10 master branch and have 6 tap devices: 
> lstack[1...6]
>
> startup.conf
> unix {
> nodaemon
> log /var/log/vpp/vpp.log
> full-coredump
> cli-listen /run/vpp/cli.sock
> gid vpp
> startup-config /home/testvpp/vpp.conf
> }
>
> api-trace {
> on
> }
>
> api-segment {
> gid vpp
> }
>
> cpu {
> main-core 2
> corelist-workers 3
> }
>
> nat {
> translation hash buckets 16000
> translation hash memory 268435456
> max translations per user 128
> }
>
> dpdk {
> num-mbufs 32768
> }
>
> Error:
> Started vector packet processing engine.
> vpp[10192]: vlib_plugin_early_init:361: plugin path 
> /usr/lib/vpp_plugins:/usr/lib64/vpp_plugins
> vpp[10192]: load_one_plugin:189: Loaded plugin: abf_plugin.so (ACL 
> based Forwarding)
> vpp[10192]: load_one_plugin:189: Loaded plugin: acl_plugin.so (Access 
> Control Lists)
> vpp[10192]: load_one_plugin:189: Loaded plugin: avf_plugin.so (Intel 
> Adaptive Virtual Function (AVF) Device Plugin)
> vpp[10192]: load_one_plugin:191: Loaded plugin: cdp_plugin.so
> vpp[10192]: load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data 
> Plane Development Kit (DPDK))
> vpp[10192]: load_one_plugin:189: Loaded plugin: flowprobe_plugin.so 
> (Flow per Packet)
> vpp[10192]: load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group 
> Based Policy)
> vpp[10192]: load_one_plugin:189: Loaded plugin: gtpu_plugin.so 
> (GTPv1-U)
> vpp[10192]: load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP 
> messaging)
> vpp[10192]: load_one_plugin:189: Loaded plugin: ila_plugin.so 
> (Identifier-locator addressing for IPv6)
> vpp[10192]: load_one_plugin:189: Loaded plugin: ioam_plugin.so 
> (Inbound OAM)
> vpp[10192]: load_one_plugin:117: Plugin disabled (default): 
> ixge_plugin.so
> vpp[10192]: load_one_plugin:189: Loaded plugin: l2e_plugin.so (L2 
> Emulation)
> vpp[10192]: load_one_plugin:189: Loaded plugin: lacp_plugin.so (Link 
> Aggregation Control Protocol)
> vpp[10192]: load_one_plugin:189: Loaded plugin: lb_plugin.so (Load 
> Balancer)
> vpp[10192]: load_one_plugin:189: Loaded plugin: mactime_plugin.so 
> (Time-based MAC source-address filter)
> vpp[10192]: load_one_plugin:189: Loaded plugin: map_plugin.so (Mapping 
> of address and port (MAP))
> vpp[10192]: load_one_plugin:189: Loaded plugin: memif_plugin.so 
> (Packet Memory Interface (experimetal))
> vpp[10192]: load_one_plugin:189: Loaded plugin: nat_plugin.so (Network 
> Address Translation)
> vpp[10192]: load_one_plugin:189: Loaded plugin: pppoe_plugin.so 
> (PPPoE)
> vpp[10192]: load_one_plugin:189: Loaded plugin: srv6ad_plugin.so 
> (Dynamic SRv6 proxy)
> vpp[10192]: load_one_plugin:189: Loaded plugin: srv6am_plugin.so 
> (Masquerading SRv6 proxy)
> vpp[10192]: load_one_plugin:189: Loaded plugin: srv6as_plugin.so 
> (Static SRv6 proxy)
> vpp[10192]: load_one_plugin:189: Loaded plugin: stn_plugin.so (VPP 
> Steals the NIC for Container integration)
> vpp[10192]: load_one_plugin:189: Loaded plugin: tlsmbedtls_plugin.so 
> (mbedtls based TLS Engine)
> vpp[10192]: load_one_plugin:189: Loaded plugin: tlsopenssl_plugin.so 
> (openssl based TLS Engine)
> vpp[10192]: load_one_plugin:117: Plugin disabled (default): 
> unittest_plugin.so
> vpp[10192]: /usr/bin/vpp[10192]: clib_elf_parse_file: open
> `linux-vdso.so.1': No such file or directory
> /usr/bin/vpp[10192]: clib_elf_parse_file: open `linux-vdso.so.1': No 
> such file or directory
> vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
> plugin: cdp_test_plugin.so
> /usr/bin/vpp[10192]: load_one_vat_plug

Re: [vpp-dev] Source Based Routing #vpp

[Dave Barach via Lists.Fd.Io]

Add graph node to the IP lookup feature arc. See attached code, from a 
known-to-work example. Program src routes into a non-default FIB.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of 
georgi.mel...@gmail.com
Sent: Monday, August 27, 2018 1:28 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Source Based Routing #vpp

Hi VPP experts,

I would like to shed light on a particular scenario/usecase that I'm trying to 
implement in VPP.

The scenario demands egress packet routing to be done based on the source IP of 
the packet rather than the destination IP. I found a similar discussion in the 
VPP mail 
archive(https://www.mail-archive.com/vpp-dev@lists.fd.io/msg06886.html), but 
the solution discussed there would not be applicable for routing multiple 
source IP packets having different routes.

I understand that we can configure multiple routing table in VPP with unique 
routes in them, but would I be able to make the FIB lookup towards a particular 
table based on source IP?

If I take an analogy from Linux kernel, does VPP support functionality similar 
to 'ip rule' command, wherein we can specify a routing table to be used for a 
particular source IP.

Looking forward to your advice and support in finding a solution to this.

Thanks & Regards,
Georgi
/* *INDENT-OFF* */
VNET_FEATURE_INIT (ip4_sdp_slookup, static) =
{
  .arc_name = "ip4-unicast",
  .node_name = "ip4-sdp-slookup",
  .runs_before = VNET_FEATURES ("ip4-lookup"),
};
/* *INDENT-ON */

/* *INDENT-OFF* */
VNET_FEATURE_INIT (ip6_sdp_slookup, static) =
{
  .arc_name = "ip6-unicast",
  .node_name = "ip6-sdp-slookup",
  .runs_before = VNET_FEATURES ("ip6-lookup"),
};
/* *INDENT-ON */


int
sdp_src_lookup_enable_disable (sdp_main_t * sm,
   u32 sw_if_index,
   u8 enable_ip4,
   u8 enable_ip6, u32 ip4_vrf_id, u32 ip6_vrf_id)
{
  vnet_sw_interface_t *sw;
  int rv = 0;
  u32 ip4_fib_index = 0, ip6_fib_index = 0;

  /* Not a physical port? */
  sw = vnet_get_sw_interface (sm->vnet_main, sw_if_index);
  if (sw->type != VNET_SW_INTERFACE_TYPE_HARDWARE)
return VNET_API_ERROR_INVALID_SW_IF_INDEX;

  if (enable_ip4)
{
  ip4_fib_index = fib_table_find (FIB_PROTOCOL_IP4, ip4_vrf_id);

  if (ip4_fib_index == ~0)
return VNET_API_ERROR_NO_SUCH_FIB;

  vec_validate (sm->ip4_fib_index_by_sw_if_index, sw_if_index);
  sm->ip4_fib_index_by_sw_if_index[sw_if_index] = ip4_fib_index;
}
  vnet_feature_enable_disable ("ip4-unicast", "ip4-sdp-slookup",
   sw_if_index, enable_ip4, 0, 0);
  if (enable_ip6)
{
  ip6_fib_index = fib_table_find (FIB_PROTOCOL_IP6, ip4_vrf_id);

  if (ip6_fib_index == ~0)
return VNET_API_ERROR_NO_SUCH_INNER_FIB;

  vec_validate (sm->ip6_fib_index_by_sw_if_index, sw_if_index);
  sm->ip6_fib_index_by_sw_if_index[sw_if_index] = ip6_fib_index;
}
  vnet_feature_enable_disable ("ip6-unicast", "ip6-sdp-slookup",
   sw_if_index, enable_ip6, 0, 0);

  return rv;
}

/*
 * node.c - sdp plugin dst lookup, policy enforcement
 *
 * Copyright (c)  
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at:
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef struct
{
  u32 next_index;
  u32 policy;
} sdp_slookup_trace_t;

/* packet trace format function */
#ifndef CLIB_MARCH_VARIANT
static u8 *
format_sdp_slookup_trace (u8 * s, va_list * args)
{
  CLIB_UNUSED (vlib_main_t * vm) = va_arg (*args, vlib_main_t *);
  CLIB_UNUSED (vlib_node_t * node) = va_arg (*args, vlib_node_t *);
  sdp_slookup_trace_t *t = va_arg (*args, sdp_slookup_trace_t *);

  s = format (s, "SDP src lookup: next index %d policy 0x%08x (%d)",
  t->next_index, t->policy, t->policy);
  return s;
}
#endif

vlib_node_registration_t sdp_slookup_node;

#define foreach_sdp_slookup_error \
_(SWAPPED, "Mac swap packets processed")

typedef enum
{
#define _(sym,str) SDP_SLOOKUP_ERROR_##sym,
  foreach_sdp_slookup_error
#undef _
SDP_SLOOKUP_N_ERROR,
} sdp_slookup_error_t;

#ifndef CLIB_MARCH_VARIANT
static char *sdp_slookup_error_strings[] = {
#define _(sym,string) string,
  foreach_sdp_slookup_error
#undef _
};
#endif

/**
 * Add the drop arc for packets that don't pass muster.
 * All other arcs are automatically added when the SDP DPO is stacked onto
 * the various parent DPO types
 */
typedef enum
{
  SDP_SLOOKUP_NEXT_DROP,
  SDP_SLOOKUP_N_NEXT,
} 

Re: [vpp-dev] received signal SIGSEGV and vpp restarts continuously

[Dave Barach via Lists.Fd.Io]

Looks like a  NULL pointer - please decode the pc. It would help if you could 
repro the problem with a debug image and send a full backtrace.

vnet[10192]: received signal SIGSEGV, PC 0x7fa62aecade3, faulting address 0x0

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of carlito nueno
Sent: Wednesday, August 22, 2018 4:07 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] received signal SIGSEGV and vpp restarts continuously

Hi all,

I am using vpp 18.10 master branch and have 6 tap devices: lstack[1...6]

startup.conf
unix {
nodaemon
log /var/log/vpp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
gid vpp
startup-config /home/testvpp/vpp.conf
}

api-trace {
on
}

api-segment {
gid vpp
}

cpu {
main-core 2
corelist-workers 3
}

nat {
translation hash buckets 16000
translation hash memory 268435456
max translations per user 128
}

dpdk {
num-mbufs 32768
}

Error:
Started vector packet processing engine.
vpp[10192]: vlib_plugin_early_init:361: plugin path 
/usr/lib/vpp_plugins:/usr/lib64/vpp_plugins
vpp[10192]: load_one_plugin:189: Loaded plugin: abf_plugin.so (ACL based 
Forwarding)
vpp[10192]: load_one_plugin:189: Loaded plugin: acl_plugin.so (Access Control 
Lists)
vpp[10192]: load_one_plugin:189: Loaded plugin: avf_plugin.so (Intel Adaptive 
Virtual Function (AVF) Device Plugin)
vpp[10192]: load_one_plugin:191: Loaded plugin: cdp_plugin.so
vpp[10192]: load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane 
Development Kit (DPDK))
vpp[10192]: load_one_plugin:189: Loaded plugin: flowprobe_plugin.so (Flow per 
Packet)
vpp[10192]: load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group Based 
Policy)
vpp[10192]: load_one_plugin:189: Loaded plugin: gtpu_plugin.so (GTPv1-U)
vpp[10192]: load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP messaging)
vpp[10192]: load_one_plugin:189: Loaded plugin: ila_plugin.so 
(Identifier-locator addressing for IPv6)
vpp[10192]: load_one_plugin:189: Loaded plugin: ioam_plugin.so (Inbound OAM)
vpp[10192]: load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
vpp[10192]: load_one_plugin:189: Loaded plugin: l2e_plugin.so (L2 Emulation)
vpp[10192]: load_one_plugin:189: Loaded plugin: lacp_plugin.so (Link 
Aggregation Control Protocol)
vpp[10192]: load_one_plugin:189: Loaded plugin: lb_plugin.so (Load Balancer)
vpp[10192]: load_one_plugin:189: Loaded plugin: mactime_plugin.so (Time-based 
MAC source-address filter)
vpp[10192]: load_one_plugin:189: Loaded plugin: map_plugin.so (Mapping of 
address and port (MAP))
vpp[10192]: load_one_plugin:189: Loaded plugin: memif_plugin.so (Packet Memory 
Interface (experimetal))
vpp[10192]: load_one_plugin:189: Loaded plugin: nat_plugin.so (Network Address 
Translation)
vpp[10192]: load_one_plugin:189: Loaded plugin: pppoe_plugin.so (PPPoE)
vpp[10192]: load_one_plugin:189: Loaded plugin: srv6ad_plugin.so (Dynamic SRv6 
proxy)
vpp[10192]: load_one_plugin:189: Loaded plugin: srv6am_plugin.so (Masquerading 
SRv6 proxy)
vpp[10192]: load_one_plugin:189: Loaded plugin: srv6as_plugin.so (Static SRv6 
proxy)
vpp[10192]: load_one_plugin:189: Loaded plugin: stn_plugin.so (VPP Steals the 
NIC for Container integration)
vpp[10192]: load_one_plugin:189: Loaded plugin: tlsmbedtls_plugin.so (mbedtls 
based TLS Engine)
vpp[10192]: load_one_plugin:189: Loaded plugin: tlsopenssl_plugin.so (openssl 
based TLS Engine)
vpp[10192]: load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: clib_elf_parse_file: open
`linux-vdso.so.1': No such file or directory
/usr/bin/vpp[10192]: clib_elf_parse_file: open `linux-vdso.so.1': No such file 
or directory
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: cdp_test_plugin.so
/usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: vxlan_gpe_ioam_export_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: udp_ping_test_plugin.so
/usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded plugin:
vxlan_gpe_ioam_export_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: dpdk_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: memif_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: nat_test_plugin.so
/usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded plugin:
udp_ping_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: lacp_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: mactime_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: ioam_pot_test_plugin.so
/usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded
plugin: ioam_trace_test_plugin.so
vpp[10192]: /usr/bin/vpp[10192]: load_one_vat_plugin:67: Loaded

Re: [vpp-dev] VPP crashes on multi core

[Dave Barach via Lists.Fd.Io]

Please refer to https://wiki.fd.io/view/VPP/BugReports for bug reporting, also 
https://wiki.fd.io/view/VPP/Configuration_Tool

If you expect folks to volunteer to help you: write up your system 
configuration, vpp version and configuration, and so forth to a reasonable 
standard.

From: vpp-dev@lists.fd.io  On Behalf Of Mehran Memarnejad
Sent: Friday, August 17, 2018 5:51 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP crashes on multi core

Hi,
In default configuration of vpp on single core, everything seems ok but when I 
want to get the most out of my hardware resources and modify vpp startup 
config, it crashes at some stages.
Here is some carshes:
1- I set interface's IP and then when I plugged cables in ports, It suddenly 
carshes and system needs to be rebooted.

2- once I set up a vpls scenario and I was passing traffics without any problem 
but when I plugged out the cable connecting PE to P router while the traffic 
was comming, vpp crashed.

In some cases, I use the same configurations but sometimes it crashes and 
sometimes it doesn't.

How should I setup VPP to make it use all hardware resources?? I mean how 
should I set CPU cores, RAM and etc??

Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10203): https://lists.fd.io/g/vpp-dev/message/10203
Mute This Topic: https://lists.fd.io/mt/24610978/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] VPP crashes with bvi interface

[Dave Barach via Lists.Fd.Io]

Almost no matter what, vpp shouldn’t crash. Please at share the backtrace. See 
https://wiki.fd.io/view/VPP/BugReports and also 
https://wiki.fd.io/view/VPP/VPP_Home_Gateway for a known-to-work similar BVI / 
IRB configuration.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Aleksander Djuric
Sent: Wednesday, August 15, 2018 9:18 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP crashes with bvi interface

Hi all,

For test purposes I've installed VPP (v18.10-rc0) on 1'st host machine with 4 
lan adapters on it. I trying to setup BVI loopback interface with ip address to 
emulate network switch. 2'nd host with ip address 
192.168.0.2/24 is connected to GigabitEthernet1/0/0. 
Interface GigabitEthernet1/0/1 is connected to router. My config for VPP is 
below:

set int state GigabitEthernet1/0/0 up
set int state GigabitEthernet1/0/1 up
set int l2 bridge GigabitEthernet1/0/0 1
set int l2 bridge GigabitEthernet1/0/1 1
loopback create
set int state loop0 up
set int l2 bridge loop0 1 bvi
set int ip address loop0 192.168.0.1/24

VPP craches in a few seconds after setting loop 0 as bvi.

Is it a bug or it's a feature?
Please help me to correct configuration if I'm wrong.

Thanks in advance,
Aleksander

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

View/Reply Online (#10166): https://lists.fd.io/g/vpp-dev/message/10166
Mute This Topic: https://lists.fd.io/mt/24533887/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] Overlapping IP/subnet support on base/vlan interface

[Dave Barach via Lists.Fd.Io]

Dear Michael,

It is completely normal for a router data plane to forbid this scenario. Given 
a packet to route to 13.13.13.114, which interface should the data plane choose?

>From what I can tell, it looks like you’re trying to route untagged as well as 
>VLAN 11 and VLAN 12 packets. This sounds like an IRB use case to me. Please 
>see 
>https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_Guide#VLAN_Tag_Rewrite

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Michael Yu
Sent: Monday, August 13, 2018 10:48 PM
To: vpp-dev 
Cc: Neale Ranns (nranns) ; Ole Troan 
Subject: Re: [vpp-dev] Overlapping IP/subnet support on base/vlan interface

Hello,

I have checked the latest code in master branch and confirm ” VPP does not 
support multiple interfaces in the same subnet” is still true.
And I can understand the commit https://gerrit.fd.io/r/#/c/8057/ is to expand 
the check of overlapping subnet to all interfaces in the same table/VRF.
>From draft check and previous discussion I can also understand that the 
>limitation is that only one fib entry (the latter one) can exist in the fib 
>table for one given subnet, but I am not sure if this is the only place 
>limitation exists.
And from what I see there is no plan to support “multiple interfaces in the 
same subnet” configuration.

Could you help confirm my understanding? Thanks.
Actually overlapping IP configuration is one of use cases we want to support in 
our project so we want to understand the limitation and to see how we can 
handle it, thanks for your help.

Best Regards
Michael

From: Yu, Michael A. (NSB - CN/Qingdao)
Sent: 2018年8月13日 14:51
To: 'Neale Ranns' mailto:nra...@cisco.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Overlapping IP/subnet support on base/vlan interface

Hello Neale and VPP experts,

We have one use case to support in VPP, to configure overlapping IP on flat 
interface and VLAN sub-interface, like below:

Eth1-- 13.13.13.114
Eth1.11  -- 13.13.13.114
Eth1.12  -- 13.13.13.114

But we found that this kind of configuration is not supported yet and below 
error would be printed after we configure one IP on the flat interface and when 
we configure the same IP on the vlan sub-interface. (we are using 18.01)

[root@localhost tools]# vppctl set int ip addr host-veth1.111 13.13.13.114/24
set interface ip address: Prefix 13.13.13.114/24 already found on interface 
host-veth1

We made some search and found in attached email it’s claimed ” VPP does not 
support multiple interfaces in the same subnet.” and 
https://gerrit.fd.io/r/#/c/8057/ was submitted to forbid this kind of 
configuration.

Our questions are that:


1. If the statement ” VPP does not support multiple interfaces in the same 
subnet” is still true in latest implementation? (my assumption is yes)

2. Is there any plan to support this kind of configuration (overlapping 
subnet or IP on flat interface and vlan sub-interface) in the future?

3. Do you know where this limitation comes from? we want to understand the 
feasibility to break this limitation.

Could you help? Thanks!

Best Regards
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10140): https://lists.fd.io/g/vpp-dev/message/10140
Mute This Topic: https://lists.fd.io/mt/24500872/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 CLI command parsing

[Dave Barach via Lists.Fd.Io]

Try this in mycmd:

u8 * line;
if (unformat (input, "%U", unformat_line, ))
   process_line;

Note that line will be a true u8 * vector: no null-termination. If you need 
null termination: vec_add1 (line, 0); 

Remember to vec_free(...) it unless you're planning to keep it.

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Monday, August 13, 2018 1:53 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding CLI command parsing

Hi,

I am relatively new to this and trying to learn the art of using 
format/unformat.
My requirement is that if my command is "mycmd" followed by some string (which 
may have spaces in it), then I should be able to read the entire string up to 
the \n character typed by the user.

Eg. if the command is typed like

mycmd foo1 foo2 foo3

(the "path" of the VLIB_CLI_COMMAND  is "mycmd") Then in my CLI callback 
function, I want to be able to get the string
"foo1 foo2 foo3" setup in a u8* variable. If the leading and trailing spaces 
are trimmed, I am fine by that. I am looking for the correct way to call the 
unformat functions in my command callback function to achieve this.

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

View/Reply Online (#10132): https://lists.fd.io/g/vpp-dev/message/10132
Mute This Topic: https://lists.fd.io/mt/24505388/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] timing_wheel or tw_timer

[Dave Barach via Lists.Fd.Io]

The tw_timer implementation is extremely fast. We routinely test it to 60 
million concurrent timers, the number required to bring up 10M TCP sessions.

Given a 500ms granularity, we have: max range = 86400 (secs/day) * 2 (clock 
ticks/second) = 172800 slots. A 2-ring, 512 slots/ring geometry would work. You 
can #include  and use that wheel geometry 
verbatim, so long as each object needs at most 16 independent timers.

Look at .../src/vppinfra/test_tw_timer.c for an example which using this 
specific ring geometry. It’s the “double_wheel” test-case.

You’ll probably need/want to add either a process node which wakes up every 
half second to run the tw_timer wheel, or an input node. Unless you have 
super-high perf / scale targets, go with the process node.

HTH... Dave


From: vpp-dev@lists.fd.io  On Behalf Of Andreas Schultz
Sent: Monday, August 13, 2018 11:54 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] timing_wheel or tw_timer

Hi,

I need to implement per session timers with about 500ms granularity. Maximum 
timer range can be up to 24 hours. Should I use the timing_wheel (like BFD 
does) or one of the tw_timer's?

And what is main difference between the timing_wheel and the tw_timer anyway?

Thanks
Andreas

--
--
Dipl.-Inform. Andreas Schultz

--- enabling your networks --
Travelping GmbH Phone:  +49-391-81 90 99 0
Roentgenstr. 13 Fax:+49-391-81 90 99 299
39108 Magdeburg Email:  
i...@travelping.com
GERMANY Web:http://www.travelping.com
Company Registration: Amtsgericht StendalReg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10131): https://lists.fd.io/g/vpp-dev/message/10131
Mute This Topic: https://lists.fd.io/mt/24504301/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] vnet tcp.h include error

[Dave Barach via Lists.Fd.Io]

Although I could explain how to fix that specific problem, please do not to use 
17.10. We don't support 17.10 anymore. 

The tcp stack worked better in 18.04, and much better than that in 18.07. I'd 
strongly suggest that you switch to 18.07...

HTH... Dave 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of ko
Sent: Monday, August 13, 2018 10:15 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vnet tcp.h include error

Hello,

I'm trying to include vnet/tcp/tcp.h to my plugin to be able to use 
format_tcp_flags. I'm getting the following error:

/usr/include/vnet/tcp/tcp.h:349:34: fatal error: vnet/tcp/tcp_error.def: 
No such file or directory

tcp_error.def is indeed not distributed with vpp-dev 17.10, but included by 
tcp.h. is this normal ?


Thanks
k

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

View/Reply Online (#10120): https://lists.fd.io/g/vpp-dev/message/10120
Mute This Topic: https://lists.fd.io/mt/24503358/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] format_bihash not printing all the elements

[Dave Barach via Lists.Fd.Io]

1 free lists
   [len 1] 1193 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817eca80
   used 207488 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

Cycle 6 out of 10...
Pick 1234 unique random keys...
Add items...
Hash table test
1234 active elements 1194 active buckets
1 free lists
   [len 1] 0 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)
Search for items 1 times...
43473665 searches per second
1234 searches in .28 seconds
Standard E-hash search for items 1 times...
1234 searches in .81 seconds
15302010 searches per second
Delete items...
Kernel RSS: 5348 bytes
Hash table test
0 active elements 0 active buckets
1 free lists
   [len 1] 1194 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

Cycle 7 out of 10...
Pick 1234 unique random keys...
Add items...
Hash table test
1234 active elements 1189 active buckets
1 free lists
   [len 1] 5 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)
Search for items 1 times...
43257265 searches per second
1234 searches in .29 seconds
Standard E-hash search for items 1 times...
1234 searches in .80 seconds
15386533 searches per second
Delete items...
Kernel RSS: 5348 bytes
Hash table test
0 active elements 0 active buckets
1 free lists
   [len 1] 1194 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

Cycle 8 out of 10...
Pick 1234 unique random keys...
Add items...
Hash table test
1234 active elements 1194 active buckets
1 free lists
   [len 1] 0 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)
Search for items 1 times...
43229987 searches per second
1234 searches in .29 seconds
Standard E-hash search for items 1 times...
1234 searches in .80 seconds
15365267 searches per second
Delete items...
Kernel RSS: 5348 bytes
Hash table test
0 active elements 0 active buckets
1 free lists
   [len 1] 1194 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecac0
   used 207552 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

Cycle 9 out of 10...
Pick 1234 unique random keys...
Add items...
Hash table test
1234 active elements 1203 active buckets
1 free lists
   [len 1] 0 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecd00
   used 208128 b (0 Mbytes) of 4293918720 b (4095 Mbytes)
Search for items 1 times...
24096856 searches per second
1234 searches in .51 seconds
Standard E-hash search for items 1 times...
1234 searches in .88 seconds
14005697 searches per second
Delete items...
Kernel RSS: 5348 bytes
Hash table test
0 active elements 0 active buckets
1 free lists
   [len 1] 1203 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecd00
   used 208128 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

End of run, should be empty...
Hash table test
0 active elements 0 active buckets
1 free lists
   [len 1] 1203 free elts
0 linear search buckets
0 cache hits, 0 cache misses
arena: base 7f61817ba000, next 7f61817ecd00
   used 208128 b (0 Mbytes) of 4293918720 b (4095 Mbytes)

From: Vijay Katamreddy (vkatamre)
Sent: Saturday, August 11, 2018 5:24 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] format_bihash not printing all the elements

Hi Dave,

Could you please let me know what params do you use for testing the 
“test_bihash_template” executable?

vec64 options  is passing, but other than that I am struggling to use without 
segmentation faults.

For this test, I don’t have any changes in the test_bihash_template or 
bihash_template.[hc] files..


# test_bihash_template nitems 1234 nbuckets 16384 ncycles 10
Segmentation fault


Thanks
Vijay

From: mailto:vpp-dev@lists.fd.io>> on behalf of 
"Vijayabhaskar Katamreddy via Lists.Fd.Io" 
mailto:vkatamre=cisco@lists.fd.io>>
Reply-To: "Vijay Katamreddy (vkatamre)" 
mailto:vkata...@cisco.com>>
Date: Wednesday, August 8, 2018 at 9:53 PM
To: "Dave Barach (dbarach)" mailto:dbar...@cisco.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>&qu

Re: [vpp-dev] Running VPP as non-root user

[Dave Barach via Lists.Fd.Io]

Which version of vpp are you running? This should work fine in 18.07 or 
master/latest...

From: vpp-dev@lists.fd.io  On Behalf Of Richard Throne
Sent: Thursday, August 9, 2018 6:35 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Running VPP as non-root user

Hi,

I need to run VPP as non-root user.
It runs fine as root but when I run as a non-root user I run into problems. 
Using same config that works for root, I ran and hit a mounting error:
vpp[29340]: dpdk_config: mount failed 1

I was expecting permissions error and thought I could solve them with 
capabilities. I added cap_sys_admin capability to the binary and reran
setcap CAP_SYS_ADMIN+eip vpp


It doesn't even load the libraries now:
/opt/opwv/integra/99.9//tools/vpp/bin/vpp: error while loading shared 
libraries: libvlibmemory.so.0: cannot open shared object file: No such file or 
directory

I get the same error when I try a minimal test:
-bash-4.2$ ./vpp unix interactive
./vpp: error while loading shared libraries: libvlibmemory.so.0: cannot open 
shared object file: No such file or directory

Anyone know where I'm going wrong?

Thanks
Richard





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

View/Reply Online (#10091): https://lists.fd.io/g/vpp-dev/message/10091
Mute This Topic: https://lists.fd.io/mt/24237968/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] Performance and CLI response degradation with inactive port

[Dave Barach via Lists.Fd.Io]

You might consider sending e-mail to the dpdk mailing list, or e.g. Ray 
Kinsella @ Intel. Pretty clearly a [dpdk] driver / HW issue.

From: vpp-dev@lists.fd.io  On Behalf Of j...@yeager1.com
Sent: Wednesday, August 8, 2018 6:46 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Performance and CLI response degradation with inactive 
port

Quick update on this: it only needs to have a fiber cable plugged into the SFP 
for it to react normally. It doesn't matter that the other end of the cable be 
connected to anything at all, just that something is present in the SFP. This 
isn't a failure scenario I'm terribly concerned about and this seems to be more 
a reaction of the NIC then of VPP. Still, if anyone has any idea what is going 
on here I'd love to know because this isn't something I expected.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10090): https://lists.fd.io/g/vpp-dev/message/10090
Mute This Topic: https://lists.fd.io/mt/24234129/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] format_bihash not printing all the elements

[Dave Barach via Lists.Fd.Io]

What is the maximum value of j at the start of the inner loop? Note that kv.key 
= i. The test replaces many, many keys on purpose.

Set TESTS += test_bihash_template in vppinfra.am

From: Vijay Katamreddy (vkatamre)
Sent: Wednesday, August 8, 2018 3:47 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: format_bihash not printing all the elements

Hi Dave,
I took code from the below routine in test_bihash_template.c

test_bihash_vec64 (test_main_t * tm)
{
…
}

  for (j = 0; j < 3; j++)
{
  for (i = 1; i <= j * 1000 + 1; i++)
 {
   kv.key = i;
   kv.value = 1;

   BV (clib_bihash_add_del) (h, , 1 /* is_add */ );
 }
   }

And changed 10 to 3.. that inserts 3003 elements.

And calling clib_format_bihash to print it, and I am seeing 2001 elements.

Could you please let me know how to build and run test_bihash_template.c .. so 
that I can add a print routine there it self and try and can share the diffs


thanks
Vijay

From: "Dave Barach (dbarach)" mailto:dbar...@cisco.com>>
Date: Wednesday, August 8, 2018 at 3:41 PM
To: "Vijay Katamreddy (vkatamre)" 
mailto:vkata...@cisco.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: format_bihash not printing all the elements

No known issues at that level. Since this sounds like a test code, can you 
share it?

Thanks... Dave

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Vijayabhaskar 
Katamreddy via Lists.Fd.Io
Sent: Wednesday, August 8, 2018 3:14 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] format_bihash not printing all the elements

Hi,

I am add/search and experimenting with bihash, and when I use format_bihash to 
print the keys/values.. active_elements count is printing incorrectly as well 
not printing all the values.
I am inserting 3003 elements in 16_8 bihash, but only 2001 elements are 
printed, any known issues?

I know that all the 3003 elements are in the list, as I am doing search, and 
able to find the same in the same hash table

Thanks
Vijay
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10076): https://lists.fd.io/g/vpp-dev/message/10076
Mute This Topic: https://lists.fd.io/mt/24232911/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] format_bihash not printing all the elements

[Dave Barach via Lists.Fd.Io]

No known issues at that level. Since this sounds like a test code, can you 
share it?

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Vijayabhaskar 
Katamreddy via Lists.Fd.Io
Sent: Wednesday, August 8, 2018 3:14 PM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] format_bihash not printing all the elements

Hi,

I am add/search and experimenting with bihash, and when I use format_bihash to 
print the keys/values.. active_elements count is printing incorrectly as well 
not printing all the values.
I am inserting 3003 elements in 16_8 bihash, but only 2001 elements are 
printed, any known issues?

I know that all the 3003 elements are in the list, as I am doing search, and 
able to find the same in the same hash table

Thanks
Vijay
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10074): https://lists.fd.io/g/vpp-dev/message/10074
Mute This Topic: https://lists.fd.io/mt/24232911/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] Traffic generator

[Dave Barach via Lists.Fd.Io]

Dear Gulakh,

As you move forward, please be careful. An arbitrary 10g NIC may or may not 
have adequate PCI bus bandwidth to handle 10gb line-rate, full-duplex @ 64 byte 
pkts. Depopulated memory channels, incorrect NUMA placement, and a host of 
other configuration errors may yield awful results.

See https://wiki.fd.io/view/VPP/Configuration_Tool.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Gulakh
Sent: Wednesday, August 8, 2018 9:08 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Traffic generator

Hi,
I have setup a VPLS scenario in VPP and now I want to test its performance to 
see whether it is able to handle customer traffics of 10G/s. i.e. customer is 
generating 10 G/s traffic
I found a dpdk-based traffic generator here 
 but I 
couldn't run it.

My Question is that how can I generate 10G/s traffic by software??

Could you please help me with any link, tutorials and etc.

Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10066): https://lists.fd.io/g/vpp-dev/message/10066
Mute This Topic: https://lists.fd.io/mt/24229782/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] missing .deb for trusty

[Dave Barach via Lists.Fd.Io]

Trusty Tahr, aka Ubuntu 14.04, is no longer supported. 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] [FD.io Helpdesk #59254] AutoReply: git.fd.io expired certificate error

[Dave Barach via RT]

Would it be possible to bump the priority of this ticket?

Thanks... Dave

From: Luke, Chris 
Sent: Monday, August 6, 2018 12:30 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: RE: git.fd.io expired certificate error

FWIW, this is why Coverity scans have stopped, too.

Chris (back from PTO)

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, August 6, 2018 11:21
To: helpd...@fd.io<mailto:helpd...@fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [EXTERNAL] [vpp-dev] git.fd.io expired certificate error

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave


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

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

[vpp-dev] git.fd.io expired certificate error

[Dave Barach via Lists.Fd.Io]

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave

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

View/Reply Online (#10049): https://lists.fd.io/g/vpp-dev/message/10049
Mute This Topic: https://lists.fd.io/mt/24210014/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] tx-errors on VPP controlled dpdk device

[Dave Barach via Lists.Fd.Io]

+1, the aggregate RX rate seems to be around 12 KPPS, the vector rate is small. 
Absent I/O silliness, one core should handle this load with no problem.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Wednesday, August 1, 2018 4:27 PM
To: chakravarthy.arise...@viasat.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] tx-errors on VPP controlled dpdk device


In VPP packet stays on the same core where it is received in majority of cases.
Handing over packet to different core is performance expensive process and we 
are trying to avoid it.
You likely need to utilise RSS on rx side to equally load your cores,
but in this specific case VPP is not overloaded, your vector rate is ~2

--
Damjan


On 1 Aug 2018, at 20:22, 
chakravarthy.arise...@viasat.com wrote:

Hi Damjan,

Thanks for your feedback. I'm running the test in AWS instances. Thus, I have 
got only VFs. I do not have access to PF. So, I'm trying to get help from AWS 
to find out.
Once I get the info, I'll post it over here. In the mean time, I looked at the 
counters that you suggested me to focus on. It looks like the packets are 
scheduled on only one core in transmit direction. Is there a way to change?

I have 3 dedicated cores (1 main core thread for stats/mgmt and 2 cores for the 
worker threads). All the Tx queues are pinned to worker thread 1. So, worker 
thread 2 is not used for transmit path at all. Is there way to spread the 
transmit queues across the threads?

Thanks
Chakri
vpp# sh threads
ID NameTypeLWPSched Policy (Priority)  
lcore  Core   Socket State
0  vpp_main  1733other (0)1 
 1  0
1  vpp_wk_0workers 1745other (0)2  
2  0
2  vpp_wk_1workers 1746other (0)3  
3  0
3   stats 1747other (0) 
   0  0  0

vpp# sh run
Thread 0 vpp_main (lcore 1)
Time 5125.9, average vectors/node 0.00, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
api-rx-from-ringany wait 0   0  
   364  1.19e40.00
cdp-process any wait 0   0  
   992  1.98e30.00
dhcp-client-process any wait 0   0  
51  3.41e30.00
dns-resolver-processany wait 0   0  
 5  4.06e30.00
dpdk-processany wait 0   0  
  1709  5.13e40.00
fib-walkany wait 0   0  
  2563  1.37e30.00
ikev2-manager-process   any wait 0   0  
  5124  7.25e20.00
ip-route-resolver-process   any wait 0   0  
51  2.64e30.00
ip4-reassembly-expire-walk  any wait 0   0  
   513  3.85e30.00
ip6-icmp-neighbor-discovery-ev  any wait 0   0  
  5124  6.92e20.00
ip6-reassembly-expire-walk  any wait 0   0  
   513  3.84e30.00
lisp-retry-service  any wait 0   0  
  2563  1.57e30.00
memif-process   any wait 0   0  
  1709  2.10e30.00
rd-cp-process   any wait 0   0  
 237212380  3.21e20.00
unix-cli-local:17active  0   0  
   580  2.05e50.00
unix-epoll-input polling  96172305   0  
 0  1.19e40.00
vpe-oam-process any wait 0   0  
  2513  1.23e30.00
---
Thread 1 vpp_wk_0 (lcore 2)
Time 5125.9, average vectors/node 4.82, last 128 main loops 0.00 per node 0.00
  vector rates in 9.5578e3, out 8.4052e3, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
VirtualFunctionEthernet0/6/0-o   active 91  91  
 0  8.59e21.00
VirtualFunctionEthernet0/6/0-t   active 91  91  
 0  

Re: [vpp-dev] Error in VPP DPDK plugin api

[Dave Barach via Lists.Fd.Io]

Seems like you may have forgotten to add my_main->msg_id_base to mp->_vl_msg_id 
when sending the reply message from your data plane plugin.

From: vpp-dev@lists.fd.io  On Behalf Of Rubina Bianchi
Sent: Wednesday, August 1, 2018 6:42 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Error in VPP DPDK plugin api

Hi Dear VPP

I added an api to DPDK plugin in VPP src/plugin/dpdk.
My api functionality is OK but my reply handler is never called 
(_reply_t_handler is implemented for api and its function signature added to 
foreach_api_msg).
When I call my api in vpp_api_test, it returns "msg_handler_internal:432: no 
handler for msg id 9" and it doesn't return retval (its job is done correctly, 
just reply has problem).

How could I fix this warning?

I also developed a client based on dpdk_test.c like as VAT, but I faced with 
missing "dpdk/api/dpdk.api.h". I checked /usr/include/vpp and /usr/include/dpdk 
and didn't find missed header. So I added dpdk/api/dpdk.api.h to 
nobase_include_HEADERS in VPP src/plugins/dpdk.am.

What is the best solution? Do you think my approach to handle it, is right?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10005): https://lists.fd.io/g/vpp-dev/message/10005
Mute This Topic: https://lists.fd.io/mt/24003854/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] Synchronous VPP-client over SHM

[Dave Barach via Lists.Fd.Io]

At least in C, it’s perfectly possible: use 
vl_client_connect_to_vlib_no_rx_pthread(...).

Follow the sketch in the default rx_thread_fn(..) pretty carefully. You’ll need 
to manually implement a non-while(1) version of vl_msg_api_queue_handler(...). 
Spin-waiting for replies will completely consume a CPU core. Such a spin-wait 
certainly requires a deadman timeout, and should do something to relinquish the 
cpu core.

Be aware that xxx_dump API messages result in multiple replies. The standard 
scheme for detecting the end of such a message set is to send an echo-request 
message immediately after xxx_dump. When the echo-reply arrives, the preceding 
message set is complete.

Personally, I wouldn’t go there. Vpp_api_test shows how to make the binary APIs 
appear to be synchronous.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla, Leela 
Sankar
Sent: Monday, July 30, 2018 5:19 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Synchronous VPP-client over SHM

Hello,

We are writing a client for VPP to configure it over the shared-memory 
interface (similar to what VAT does).

I see that there is a rx_thread for processing responses from the server (VPP) 
to process the replies asynchronously.

Do we need to use the thread? Or Can we get rid of it and process the responses 
synchronously probably by introducing a wait if there is only one request at 
time from the client?

This way I can use the same request context to catch the “reply_t” structure.  
If it works, I can have request – response in a single call and return the 
response structure.

Please let me know if I can get rid of the rx_thread and handle this 
synchronously.

Thanks,
Leela sankar
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9977): https://lists.fd.io/g/vpp-dev/message/9977
Mute This Topic: https://lists.fd.io/mt/23864436/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] CSIT - sw_interface_set_flags admin-up link-up failing

[Dave Barach via Lists.Fd.Io]

Before doing anything else: please revert to the previous DPDK version and see 
if the issue vanishes.

From: vpp-dev@lists.fd.io  On Behalf Of Peter Mikus via 
Lists.Fd.Io
Sent: Monday, July 30, 2018 3:02 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

Hello vpp-dev,

I am looking for consultation. We started to test VPP for report on all LF CSIT 
testbeds Skylakes and Haswells.
We are observing weird behavior. In each test we are using sequence to first 
bring the both interfaces (physical up) by VAT:

  sw_interface_set_flags sw_if_index  admin-up (I also tried 
sw_interface_set_flags sw_if_index idx admin-up link-up)

After setting all interfaces UP we are testing if interfaces are really UP by 
VAT (loop 30times, 1s between API call check): "sw_interface_dump".
It wasn't an issue in past but recently we start seeing that sw_interface_dump 
is reporting interfaces as link_down (admin-up).

Notes/symptoms:
-   Our sw_interface_dump check is running 30x (1s interval) in loop.
-   Link-down is random, sometimes both interfaces are link-up sometimes just 
one and sometimes both link are down.
-   It is not TB related, nor cabling related, we see it on Haswells-3node in 
like 1 out of 70 tests, Skylakes-2node 1 out of 70, but on Skylake-3node more 
than half of the tests.
-   Checking state during test reveals that interfaces are link-down (show int) 
so "sw_interface_dump" is reporting state correctly.
-   Doing CLI during test "set interface state ... up" does bring interfaces UP 
-> (but it is hard to check the timing here).
-   Affected are mostly x520 and x710, but that is most probably because of 
statistics (low coverage of other NICs like xxv710 and xl710).
-   We have seen this in master vpp as well as rc2 vpp.
-   It is not clear when this starts to happen, so bisecting would take lot of 
time.
-   This was spotted on VIRL as well also on Memif interface which bring us to 
suspicious that this is related to API not HW.

Do you have an idea what we could check further? VPP is not crashing so no core 
dump are available. This issue is not 100% replicable which makes it hard to 
debug.

Is there a way to get more verbose error from the api call mentioned to reveal 
more information?

Thank you.

Peter Mikus
Engineer - Software
Cisco Systems Limited
[http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

View/Reply Online (#9972): https://lists.fd.io/g/vpp-dev/message/9972
Mute This Topic: https://lists.fd.io/mt/23857615/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] target symbol

[Dave Barach via Lists.Fd.Io]

I don't understand what you mean by "reserve symbols." Please explain what 
you're trying to do in more detail.

From: vpp-dev@lists.fd.io  On Behalf Of xulang
Sent: Sunday, July 29, 2018 2:43 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] target symbol

Hi all,
How can I reserve symbols in the target file vpp, what should I do to the 
Makefile under build-root.


Regards,
xiaoC



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

View/Reply Online (#9965): https://lists.fd.io/g/vpp-dev/message/9965
Mute This Topic: https://lists.fd.io/mt/23848314/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 /var/run/.rte_config

[Dave Barach via Lists.Fd.Io]

If you want to attempt a manual cherry-pick: https://gerrit.fd.io/r/#/c/13745 - 
merged a couple of days ago - would be the right place to start.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Saturday, July 28, 2018 7:20 AM
To: Prashant Upadhyaya 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding /var/run/.rte_config

Dear Prashant,

"git blame" is your friend. He can easily tell you which patch introduced that 
functionality.
And than you can try to cherry-pick it on top of 18.01

--
Damjan


On 28 Jul 2018, at 07:27, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi again Damjan,

I am currently using VPP release 18.01 which just has the tx capture
functionality.
I see that VPP release 18.07 has introduced the rx capture functionality.

At the moment, upgrading my release to 18.01 is not an option.
Can you please advise how easy or difficult it will be to backport the
rx capture functionality and add it as a patch to 18.01.

Regards
-Prashant

On Thu, Jul 26, 2018 at 4:56 PM, Prashant Upadhyaya
mailto:praupadhy...@gmail.com>> wrote:

Thanks Damjan,

I had a temporary brain-freeze, I do see there is a max parameter as well.

Regards
-Prashant


On Thu, Jul 26, 2018 at 4:46 PM, Prashant Upadhyaya
mailto:praupadhy...@gmail.com>> wrote:

Hi Damjan,

Thanks for your CLI pointers.
It seems there is a limit of 100 packets which would work against my
requirements.
If you have any suggestions there before I look into the code to
tinker with the 100, please do let me know.

Regards
-Prashant


On Thu, Jul 26, 2018 at 4:24 PM, Damjan Marion 
mailto:dmar...@me.com>> wrote:

Dear Prashant,

Try "pcap rx trace" and "pcap tx trace" command.

https://git.fd.io/vpp/tree/src/plugins/dpdk/device/cli.c#n373

Also please note that VPP packet generator (pg) supports both pcap play and
capture...

--
Damjan

On 26 Jul 2018, at 12:42, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi Damjan,

I was hoping to use the dpdk-pdump utility (built as part of DPDK) to
generate the pcap files for traffic passing through the various ports.
I have used that successfully with pure vanilla DPDK primary processes
(non VPP usecases). It runs as a secondary process.

Well, my requirement is to generate pcap's for ports on both tx and rx
-- if you have an alternate VPP-core solution, that would be great.

Regards
-Prashant


On Wed, Jul 25, 2018 at 11:32 PM, Damjan Marion 
mailto:dmar...@me.com>> wrote:


Dear Prashant,

We had lot of operational issues with dpdk leftover files in the past, so
we took special care to made them disappear ASAP.

Even if they are present you will not be able to use secondary process,
we simply don't support that use case. Secondary process will not be
able to access buffer memory as buffer memory is allocated by VPP and not by
DPDK.

Please note that VPP is not application built on top of DPDK, for us DPDK is
just
source of device drivers wit a bit of weight around them. Typical VPP
feature
code can work even without DPDK being present.

If you explain your use case we might be able to advise you how to approach
your problem
in a way native to VPP,  without relying on DPDK legacy features.

Regards,

--
Damjan

On 25 Jul 2018, at 13:11, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi,

I am running VPP with DPDK plugin.
I see that when I normally run other non VPP DPDK applications, they
create a file called /var/run/.rte_config
But VPP running as a DPDK application (and calling rte_eal_init) does
not create this file.

There are consequences of the above in certain usecases where
secondary processes try to look at this file.

Can somebody advise why this file is not created when VPP is run with
DPDK plugin. Or what needs to be done so that it does get created, or
perhaps it is getting created somewhere that I am not aware of. I am
running VPP as root.

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

View/Reply Online (#9929): https://lists.fd.io/g/vpp-dev/message/9929
Mute This Topic: https://lists.fd.io/mt/23811660/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-



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

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

Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

[Dave Barach via Lists.Fd.Io]

Guys,

The current behavior is probably not what the code author intended. It’s easy 
to change. I’ve already offered under separate cover to push a draft patch 
which won’t do this under any circumstances, so folks can kick the tires.

In its final form, a command-line argument of the form “... cpu { 
no-thread-affinity } ...”

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Peter Mikus via 
Lists.Fd.Io
Sent: Friday, July 27, 2018 2:46 PM
To: Maciek Konstantynowicz (mkonstan) ; Alec Hothan 
(ahothan) ; Juraj Linkeš ; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

Hello,


  *   What is the “significant problem” you’re running into?

The problem can be better described as: When python is spawning N instances of 
VPP process, all processes are from unknown reason placed with affinity 0x2 
(bin 10). This can be verified by taskset –p . CFS is then placing all 
VPP process to the same core, making it inefficient on multicore jenkins slave 
container.
The default vpp startup.conf is not modified thus there is no input to know 
where to pin the vpp threads. Simply one can said or think that this is related 
to python multiprocess/subprocess.popen code, which is hard-setting affinity 
mask to 0x2.

There are multiple solutions for workaround that Juraj proposed or Maciek, but 
none of them is answering why is this happening.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: csit-...@lists.fd.io 
[mailto:csit-...@lists.fd.io] On Behalf Of Maciek Konstantynowicz (mkonstan) 
via Lists.Fd.Io
Sent: Friday, July 27, 2018 6:53 PM
To: Alec Hothan (ahothan) mailto:ahot...@cisco.com>>; Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Cc: csit-...@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

Alec, This is about make test and not real packet forwarding. Per Juraj’s patch 
[1]

Juraj, My understanding is that if you’re starting VPP without specifying core 
placement in startup.conf [2] cpu {..}, then Linux CFS will be placing the 
threads onto available cpu core resources. If you’re saying this is not the 
case, and indeed the wiki comment indicates this, then the way to address it is 
to specify different core for main.c thread per vpp instance.

What is the “significant problem” you’re running into? Are tests not executing 
in parallel using python multiprocessing, are vpp’s having issues, else? Could 
you describe it a bit more?

-Maciek

[1] https://gerrit.fd.io/r/#/c/13491/
[2] https://git.fd.io/vpp/tree/src/vpp/conf/startup.conf

On 27 Jul 2018, at 17:23, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:

Hi Juraj,
How many instances and what level of performance are you looking at?
Even if you assign different cores to each VPP instance, results can be skewed 
due to interference at the LLC and PCIe/NIC level (this can be somewhat 
mitigated by running on separate sockets)

   Alec


From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Friday, July 27, 2018 at 7:25 AM
To: "Maciek Konstantynowicz (mkonstan)" 
mailto:mkons...@cisco.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, csit-dev 
mailto:csit-...@lists.fd.io>>
Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework

Hi Maciek and vpp-devs,

I've run into a significant problem regarding VPP assignment to cores. All VPPs 
that are spawned are assigned to core 1. I looked at 
https://wiki.fd.io/view/VPP/Command-line_Arguments and I guess it's because 
that's the default behavior of VPP (dpdk coremask is not configured and  Note 
that the "main" thread always occupies the lowest core-id specified in the DPDK 
[process-level] coremask.").

Is my reading of the config options accurate?

Obviously, all VPP instances running on the same core goes against running the 
tests on multiple cores. There are a couple of solutions that come to mind:
• Assign VPP instances to cores manually. With possible multiple jobs 
running on a given host, this creates a situation where the different jobs 
don't know cores are already occupied (and by how many VPP instances) and thus 
introduces additional challenges to solve.
• Add an option to override this default behavior and let the Linux CFS 
scheduler assign VPPs to cores or something similar where VPPs would land on 
different cores.

Is there some other solution?

Vpp-devs, what do you think about the second solution? What it be possible?

Thanks,
Juraj

From: Maciek Konstantynowicz (mkonstan) [mailto:mkons...@cisco.com]
Sent: Wednesday, July 25, 2018 1:10 PM
To: Juraj Linkeš mailto:juraj.lin...@pantheon.tech>>
Cc: vpp-dev@lists.fd.io; csit-dev 
mailto:csit-...@lists.fd.io>>
Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework





On 19 Jul 2018, at 15:44, 

Re: [vpp-dev] Manual patch verify request: gerrit 13769

[Dave Barach via Lists.Fd.Io]

Thanks very much... Dave

From: Tina Tsou 
Sent: Friday, July 27, 2018 1:51 PM
To: Dave Barach (dbarach) 
Cc: Brian Brooks ; vpp-dev@lists.fd.io
Subject: Re: Manual patch verify request: gerrit 13769

Dear Dave,

Looking into it...

Thank you,
Tina

On Jul 27, 2018, at 7:23 AM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
Folks,

Would it be possible for someone to download and manually verify that 
https://gerrit.fd.io/r/#/c/13769 is functionally correct, and that the proposed 
change isn’t a performance disaster on aarch64?

Thanks... Dave

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Manual patch verify request: gerrit 13769

[Dave Barach via Lists.Fd.Io]

Folks,

Would it be possible for someone to download and manually verify that 
https://gerrit.fd.io/r/#/c/13769 is functionally correct, and that the proposed 
change isn't a performance disaster on aarch64?

Thanks... Dave

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

View/Reply Online (#9949): https://lists.fd.io/g/vpp-dev/message/9949
Mute This Topic: https://lists.fd.io/mt/23832194/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] IPFIX based on classifier test case failure

[Dave Barach via Lists.Fd.Io]

If you send the vpp_api_test script sequence and the traffic profile - what the 
packets which should hit but do not actually look like - I'll take a look. It 
might be pretty simple...

D.

From: vpp-dev@lists.fd.io  On Behalf Of Jan Gelety via 
Lists.Fd.Io
Sent: Tuesday, July 24, 2018 10:43 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] IPFIX based on classifier test case failure

Hello,

As part of CSIT_VIRL phased migration we are porting VIRL tests to vpp make 
tests and IPFIX based on classify tables is the last p0 (must_be) test case to 
be ported.

Unfortunately we are facing some issues. Configuration of classify table and 
IPFIX exporter is based on VAT command sequence (please, see VPP ticket 
VPP-1354 [1] for more details) but we are getting different results:

  *   Sent packets don't hit the created session but the new session is added
  *   IPFIX report contains only packetTotalCount information and the second 
parameter (e.g. sourceIPv4Address)  is missing

Could anybody help there, please?

However, we can see that there is already flowprobe feature test case in vpp 
make test that uses IPFIX exporter too - so can we skip porting of IPFIX based 
on classifier test case from VIRL to vpp make test?

Thanks,
Jan

[1] https://jira.fd.io/browse/VPP-1354
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9922): https://lists.fd.io/g/vpp-dev/message/9922
Mute This Topic: https://lists.fd.io/mt/23803472/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] Sample plugin doest not show up with vpp 18.07

[Dave Barach via Lists.Fd.Io]

Please don’t remove extern declarations from header files...

Damjan is exactly right. It’s oh so easy to end up with N separate, independent 
but identically-named data structure instances. It’s super-confusing when that 
happens.

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of 
abdul.ma...@sofioni.com
Sent: Friday, July 20, 2018 12:04 PM
To: dmar...@me.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sample plugin doest not show up with vpp 18.07


I think its the same if we define sample_main variable in sample.c file or if 
we remove the key word extern in sample.h. I have tried removing extern and it 
works but defining sample_main in .c file should also work.




On 2018-07-20 19:02, Damjan Marion via Lists.Fd.Io wrote:

This should be the proper fix for your issue:

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

Please confirm...

--
Damjan


On 20 Jul 2018, at 15:52, 
abdul.ma...@sofioni.com wrote:


When I ran vpp 18.07 in interactive mode I found that vpp was unable to load 
sample_plugin due to an error of undefined variable *sample_main* used in 
sample.c file. However, *sample_main* is defined in sample.h file as follows.

extern sample_main_t sample_main;

Removing keyword extern worked for me. Now vpp 18.07 successfully loads 
sample_plugin.




On 2018-07-18 18:22, abdul.ma...@sofioni.com 
wrote:

Hello All,

I am trying to build vpp stable/1807 with sample plugin enabled on ubuntu 
16.04.2 using following guide.

https://docs.fd.io/vpp/18.07/sample_plugin_doc.html

Build process goes without any error and then I make .deb packages and install 
these packages on a different host (ubuntu 16.04.2) but when I check vpp 
plugins using vppctl show plugins command; I see many plugins except sample 
plugin. I also don't see any sample plugin under /usr/lib/vpp_plugins 
directory. Should I need to do any additional step.

Note: I did the same process for vpp stable/1707 and it went through perfectly 
fine and I was able to use and test vpp sample plugin.



Thanks

Regards,

Abdul Malik

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

View/Reply Online (#9876): https://lists.fd.io/g/vpp-dev/message/9876
Mute This Topic: https://lists.fd.io/mt/23670834/1123042
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[abdul.ma...@sofioni.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9898): https://lists.fd.io/g/vpp-dev/message/9898
Mute This Topic: https://lists.fd.io/mt/23670834/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#9899): https://lists.fd.io/g/vpp-dev/message/9899
Mute This Topic: https://lists.fd.io/mt/23670834/1123042
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[abdul.ma...@sofioni.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [SUSPECTED SPAM] [vpp-dev] Interface Mib II counters

[Dave Barach via Lists.Fd.Io]

I would expect very little if any measurable effect on forwarding performance. 
At least for the counters that I moved to the stats segment: vpp was already 
maintaining them. Not much changed.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Dave Cornejo
Sent: Thursday, July 19, 2018 5:22 PM
To: Ole Troan 
Cc: Ray Kinsella ; Rubina Bianchi ; John 
DeNisco (jdenisco) ; vpp-dev@lists.fd.io
Subject: Re: [SUSPECTED SPAM] [vpp-dev] Interface Mib II counters

We are starting to use the new api, it looks good, thanks for this. 
Documentation would be very appreciated

Any idea how much more evolving it’s going to do?

Is there any impact on performance of vector processing from using it?


Dave c


On Thu, Jul 19, 2018 at 12:04 AM Ole Troan 
mailto:otr...@employees.org>> wrote:
Hi Ray,

> This looks like something that really deserves to be documented, 
> _particularly_ the stats api & client?

Yes. Very much so.

> Has anyone written anything here that we can use?

Not yet. The feature is somewhat experimental.
And there are still a few bits missing with regards to the client side. On the 
VPP side the only thing requires is giving the existing counter a name, so 
that's pretty minimal.
Let me try to write something down while we're evolving the feature (I'd very 
much like to hear from people who are interested in using the new stats infra), 
and then that can be used as a base for writing user documentation.

Cheers,
Ole

>
> Ray K
>
> On 16/07/2018 03:46, Ole Troan wrote:
>> Hi Rubina,
>>> I wanna extract stats of vpp interfaces (specially information about 
>>> traffic, ie. bytes out, bytes in, ...) and set them to relevant snmp oid.
>>> Is there any VPP infrastructure to do that?
>>> If not, what is the efficient way to extract data?
>> The most efficient (and new) way to extract stats is through the shared 
>> memory segment for counters.
>> See commit 048a4e5a.
>> Then you could build an external SNMP agent scraping counters. There is an 
>> example usage in the stats_client.c file.
>> I'm also working on building more client support, including for Python. I 
>> just need to get back from holidays first.
>> Cheers,
>> Ole
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#9846): https://lists.fd.io/g/vpp-dev/message/9846
>> Mute This Topic: https://lists.fd.io/mt/23483393/675355
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
>> [m...@ashroe.eu]
>> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#9884): https://lists.fd.io/g/vpp-dev/message/9884
Mute This Topic: https://lists.fd.io/mt/23743214/675631
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dcorn...@netgate.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] All master/latest patches currently failing validation...

[Dave Barach via Lists.Fd.Io]

We missed a step when pulling the release throttle which causes the JVPP tests 
to fail.

As soon as we merge https://gerrit.fd.io/r/#/c/13522, order should be restored.

We need to wait until that one passes validation, for obvious reasons.

Thanks... Dave

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

View/Reply Online (#9860): https://lists.fd.io/g/vpp-dev/message/9860
Mute This Topic: https://lists.fd.io/mt/23586467/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] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..

[Dave Barach via Lists.Fd.Io]

Makes sense, but it’s a pain when the wheels fall off.

Perhaps we should make the virl job non-voting as soon as Maciek thinks we have 
all P0 test gaps covered?

D.

From: vpp-dev@lists.fd.io  On Behalf Of Ed Kern via 
Lists.Fd.Io
Sent: Friday, July 13, 2018 10:11 AM
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in 
progress..




On Jul 13, 2018, at 5:37 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES 
at Cisco) via Lists.Fd.Io 
mailto:vrpolak=cisco@lists.fd.io>> wrote:

> Not sure what exactly happened

It went like this:

0. Patch set 2 is uploaded.
1. Both clang and virl jobs (among others) are triggered.
2. Both jobs fail (virl on the usual NFS mount symptom).
3. Virl job has naginator, so its result is reported as NOT_BUILT.
4. Clang is reported as FAILURE, so vote is -1.
5. Naginator triggers another run of virl job (only).
6. This time virl job is SUCCESS.
7. Jenkins sees no falure in all 1 job from latest trigger, so votes +1.


This is more or less accurate.


I am not sure we can explain Jenkins that
results from previous trigger rounds still aply (if not superseded).

new incoming vote is an overwrite thats just what it does.



I recommend to disable naginator on the virl job
and rely on methods which trigger all verify jobs.


There are no automatic functions to re-trigger all jobs.  So your suggesting 
here is return to a ton of manual
rechecks for multiple different possible triggers.

The above behavior is not new.  It is just rare.

If A job fails twice faster than B job fails and then passes you will end up in 
this state.

In this case the clang job is especially prone to this because it is a short 
duration job that when it
fails it does so quickly..  (2,5,6 minutes)   So it can actually fail twice 
(properly) within 10 minutes.
The virl job can take 30 minutes (because it does a build first) before it gets 
to the point where
we see intermittent failures.  So your looking at @80 minutes to get a proper 
vote from the virl
job (intermittent failure to success).

I can remove the retry on virl jobs if that is what the committers would like 
me to do.   But with the virl
jobs on the road to deprecation, and hopefully some traction fixing the 
LF/vexxhost network issues
causing so many hudson/jnlp errors, I wouldn’t be voting for this path.

Ed



Vratko.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via Lists.Fd.Io
Sent: Friday, 2018-July-13 10:59
To: Marco Varlese mailto:mvarl...@suse.de>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in 
progress..


Version 1 of the same patch failed properly, for the same error message, then I 
removed
permute inline functions and left blend as i missed that same error happens 
also for blend.

Not sure what exactly happened, but it doesn't look like it is not configured 
for voting as it worked properly for PatchSet 1 ...

Reason why this is failing on clang is that clang guys use 
__builtin_shufflevector for multiple
intel intrinsics, and that builtin insist on immediate value for some 
parameters, and it refuses to use
inline function argument, even if that argument is constant.

I will need to redo this with __asm__ ()

--
Damjan



On 13 Jul 2018, at 09:49, Marco Varlese 
mailto:mvarl...@suse.de>> wrote:

Hi Dave & allm

Sorry about that,I actually merged the patch. However, it was indeed Verified+1 
:(

I have gone now to see the actual CLANG build failure and wondering: is it 
possible that job is not configured as voting/gating job in Jenkins so the 
verification process succeeds anyway?


- Marco

On Thu, 2018-07-12 at 22:49 +, Dave Barach via Lists.Fd.Io wrote:
Revert complete... HTH... Dave

From: Dave Barach (dbarach)
Sent: Thursday, July 12, 2018 5:01 PM
To: Damjan Marion (damarion) mailto:damar...@cisco.com>>; 
Florin Coras (fcoras) mailto:fco...@cisco.com>>; 'Marco 
Varlese' mailto:mvarl...@suse.de>>; Ed Kern (ejk) 
mailto:e...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..
Importance: High

Folks,

Unfortunately, the AVX2 blend patch causes 100% clang validation failures on 
unrelated patches. The clang validation job actually failed on the original 
patch, but somehow fd.io<http://fd.io/> JJB voted +1 anyhow.

See https://gerrit.fd.io/r/#/c/13457 – revert, https://gerrit.fd.io/r/#/c/13408 
- original patch.

Thanks... Dave


-=-=-=-=-=-=-=-=-=-=-=-

Links: You receive all messages sent to this group.



View/Reply Online (#9830): https://lists.fd.io/g/vpp-dev/message/9830

Mute This Topic: https://lists.fd.io/mt/23297899/675056

Group Owner: vpp-dev+ow...@lists.

Re: [vpp-dev] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..

[Dave Barach via Lists.Fd.Io]

Revert complete... HTH... Dave

From: Dave Barach (dbarach)
Sent: Thursday, July 12, 2018 5:01 PM
To: Damjan Marion (damarion) ; Florin Coras (fcoras) 
; 'Marco Varlese' ; Ed Kern (ejk) 

Cc: vpp-dev@lists.fd.io
Subject: Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..
Importance: High

Folks,

Unfortunately, the AVX2 blend patch causes 100% clang validation failures on 
unrelated patches. The clang validation job actually failed on the original 
patch, but somehow fd.io JJB voted +1 anyhow.

See https://gerrit.fd.io/r/#/c/13457 - revert, https://gerrit.fd.io/r/#/c/13408 
- original patch.

Thanks... Dave

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

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

[vpp-dev] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..

[Dave Barach via Lists.Fd.Io]

Folks,

Unfortunately, the AVX2 blend patch causes 100% clang validation failures on 
unrelated patches. The clang validation job actually failed on the original 
patch, but somehow fd.io JJB voted +1 anyhow.

See https://gerrit.fd.io/r/#/c/13457 - revert, https://gerrit.fd.io/r/#/c/13408 
- original patch.

Thanks... Dave

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

View/Reply Online (#9828): https://lists.fd.io/g/vpp-dev/message/9828
Mute This Topic: https://lists.fd.io/mt/23297899/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] DPDK and VPP Relationship

[Dave Barach via Lists.Fd.Io]

What you wrote is not correct.

DPDK drivers run in user-mode, as part of the vpp executable. To a first 
approximation: device drivers use the uio_pci_generic kernel module to map 
device registers into user-space. Once that happens, user-mode device drivers – 
either dpdk or vpp native – manipulate the device registers directly. No 
transition to kernel mode and/or system calls are required on a regular basis.

Device RX and TX rings are allocated from hugetlb pages (aka non-pageable 
memory), mmap’ed into the vpp+dpdk address space.

In short, the kernel is simply not involved in packet processing.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Gulakh
Sent: Wednesday, July 11, 2018 7:19 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] DPDK and VPP Relationship

Hi,
I have a question about DPDK and VPP.
As far as I know, DPDK has some NIC drivers developed for some types of NICs. 
These drivers are Linux device drivers that are installed as kernel module e.g. 
uio_pci_generic and ixgbe (yes?).

In Linux , kernel modules have the as privilege as the Linux kernel. So DPDK 
NIC drivers run in kernel space (yes?)

When a packet comes in, It is first received by DPDK drivers in kernel mode. As 
VPP runs in user space, there must be a context switch to deliver packet to VPP.
Now if VPP decides that the packet should be forwarded to some next hop, then 
the packet must have another context switch from user space to kernel space, 
meaning that to forward a packet which is not destined to us, we have to 
tolerate two context switch that is not necessary.

I guess (because I have seen an L3 forwarding sample in DPDK sample programs 
but I did not dive into it to see what it did)  that DPDK has a FIB by which it 
can decide what to do with the received packet without the need of context 
switch(all done in kernel space).

I summary:
I think that we have 3 ways to handle a received packet:

1- Send it from DPDK to VPP and tolerate two context switch
  Question: if that is the case, Why do we need to tolerate 2 context 
switch that is not necessary?

2- Have a FIB in DPDK and forward the received packet directly in kernel space
 Question: if that is the case, How does VPP show this packet in its 
show trace because VPP is unaware of this packet?

3- Another solution that I do not know 
  Question: Please tell me the procedure

Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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