Re: [vpp-dev] Regarding DPDK's rte_timer api's usage with VPP

[Dave Barach]

How about replacing this part of rte_timer_subsystem_init(): 

mz = rte_memzone_lookup(mz_name);
if (mz == NULL) {
mz = rte_memzone_reserve_aligned(mz_name, mem_size,
SOCKET_ID_ANY, 0, RTE_CACHE_LINE_SIZE);
if (mz == NULL) {
rte_mcfg_timer_unlock();
return -ENOMEM;
}
do_full_init = true;
} else
do_full_init = false;

with either a call to clib_mem_alloc_aligned() or clib_pmalloc_alloc_aligned() 
depending on mem_size? There appears to be one
call to rte_memzone_free() which would also need an adjustment.

FWIW... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Monday, March 27, 2023 1:07 AM
To: vpp-dev 
Subject: [vpp-dev] Regarding DPDK's rte_timer api's usage with VPP

Hi,

I am bringing in some legacy code which worked with DPDK standalone, and 
converting it into a VPP plugin (VPP 22.10) The legacy code uses the DPDK 
rte_timer api's Now as soon as my VPP plugin calls the DPDK API 
rte_timer_subsystem_init, I get the following error from EAL of DPDK

EAL: memzone_reserve_aligned_thread_unsafe(): Number of requested memzone 
segments exceeds RTE_MAX_MEMZONE

Of course I can uproot the entire timer implementation in legacy code and 
replace it with various other alternatives, but if I can get over the issue I 
have reported above somehow that would be great.

If anybody has resolved a similar issue, please do advise.

Regards
-Prashant


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22771): https://lists.fd.io/g/vpp-dev/message/22771
Mute This Topic: https://lists.fd.io/mt/97876096/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] How to check stack size of process node

[Dave Barach]

Find the current process index: vlib_node_main_t *nm = >node_main; 
current_process_index = nm->current_process_index;

 

Find the process object:   vlib_process_t *p = vec_elt (nm->processes, 
current_process_index);

 

Find the stack base: p->stack

 

Take the address of a local variable in a function at what you think is the 
maximum stack depth, and subtract. That’s the instantaneous stack depth. 

 

You can sprinkle “stack_depth_now = p->stack -  if (stack_depth_now > 
max_stack_depth) max = now” cookies in various places.

 

HTH...

 

From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Friday, March 24, 2023 9:24 AM
To: vpp-dev 
Subject: Re: [vpp-dev] How to check stack size of process node

 

Hi,

 

Please share any thoughts on this.

 

Thanks,

 

On Sat, Mar 18, 2023, 13:18 chetan bhasin via lists.fd.io   
mailto:gmail@lists.fd.io> > wrote:

Hi vpp-team,

 

 

Could you please provide a way via which a process node stack size can be 
calculated. We are creating a process node, how to figure out the value of 
process_log2_n_stack_bytes??

 

Thanks,

 






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22764): https://lists.fd.io/g/vpp-dev/message/22764
Mute This Topic: https://lists.fd.io/mt/97689882/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Race condition between bihash deletion and searching - misuse or bug?

[Dave Barach]

Please see https://gerrit.fd.io/r/c/vpp/+/38507 

 

-Original Message-

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Hao Tian

Sent: Wednesday, March 15, 2023 10:14 PM

To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 

Subject: Re: [vpp-dev] Race condition between bihash deletion and searching - 
misuse or bug?

 

Hi Dave,

 

Thanks for your work. I am ready to test whenever needed.

 

Best regards,

Hao Tian

 



From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > on behalf of Dave Barach mailto:v...@barachs.net> >

Sent: Thursday, March 16, 2023 7:02 AM

To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 

Subject: Re: [vpp-dev] Race condition between bihash deletion and searching - 
misuse or bug?

 

I'm doing a bit of work to straighten out the template, hopefully without 
causing a measurable performance regression.

 

Hao's test code is a bit of a corner-case: there is exactly one record in the 
database which the code thrashes as hard as possible.

 

D.

 

-Original Message-

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Andrew Yourtchenko

Sent: Wednesday, March 15, 2023 12:33 PM

To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 

Subject: Re: [vpp-dev] Race condition between bihash deletion and searching - 
misuse or bug?

 

Hao,

 

I noticed the same behavior when stress-testing the multi thread session 
handling for the ACL plugin a while ago. I thought this trade off is there to 
avoid having to do the hard locks in bihash code, rather than it being a bug.

 

As you say - the special value comes only if the deletion is in progress, and 
it is always the same. So I just treated that case in my code same as “not 
found”.

 

My logic was: if an entry is just in process of being deleted, there is very 
little use for its old value anyway.

 

--a

 

> On 15 Mar 2023, at 14:45, Hao Tian  <mailto:tianhao...@outlook.com> > wrote:

> 

> Hi,

> 

> I tried but could not come up with any way that is able to ensure the kvp 
> being valid upon return without using the full bucket lock.

> 

> Maybe we can make a copy of the value before returning, validate the copy and 
> return that copy instead. Critical section can be shrinked to cover only the 
> copying process, which seems to perform better, but I'm not sure if this is 
> the best approach.

> 

> Could you please shed some light here? Thanks!

> 

> Regards,

> Hao Tian

> 

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22714): https://lists.fd.io/g/vpp-dev/message/22714
Mute This Topic: https://lists.fd.io/mt/97599770/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Race condition between bihash deletion and searching - misuse or bug?

[Dave Barach]

I'm doing a bit of work to straighten out the template, hopefully without 
causing a measurable performance regression.

Hao's test code is a bit of a corner-case: there is exactly one record in the 
database which the code thrashes as hard as possible.

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Wednesday, March 15, 2023 12:33 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching - 
misuse or bug?

Hao,

I noticed the same behavior when stress-testing the multi thread session 
handling for the ACL plugin a while ago. I thought this trade off is there to 
avoid having to do the hard locks in bihash code, rather than it being a bug.

As you say - the special value comes only if the deletion is in progress, and 
it is always the same. So I just treated that case in my code same as “not 
found”.

My logic was: if an entry is just in process of being deleted, there is very 
little use for its old value anyway.

--a

> On 15 Mar 2023, at 14:45, Hao Tian  wrote:
> 
> Hi,
> 
> I tried but could not come up with any way that is able to ensure the kvp 
> being valid upon return without using the full bucket lock.
> 
> Maybe we can make a copy of the value before returning, validate the copy and 
> return that copy instead. Critical section can be shrinked to cover only the 
> copying process, which seems to perform better, but I'm not sure if this is 
> the best approach.
> 
> Could you please shed some light here? Thanks!
> 
> Regards,
> Hao Tian
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22711): https://lists.fd.io/g/vpp-dev/message/22711
Mute This Topic: https://lists.fd.io/mt/97599770/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Race condition between bihash deletion and searching - misuse or bug?

[Dave Barach]

Doubling the number of atomic ops was expected to cause a severe performance
regression. This hack demonstrates that the test code wasn't responsible. A
bit of extra suspicion in clib_bihash_search_inline_2_with_hash() will
likely solve the problem without the huge performance regression. 

D.  

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Hao Tian
Sent: Tuesday, March 14, 2023 9:47 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching
- misuse or bug?

Hi,

I've done the change you asked, and the "suspicious value" warnings are all
gone. Here is the diff:

diff --git a/src/vppinfra/bihash_template.h b/src/vppinfra/bihash_template.h
index c4e120e4a..b9f658db3 100644
--- a/src/vppinfra/bihash_template.h
+++ b/src/vppinfra/bihash_template.h
@@ -532,12 +532,7 @@ static inline int BV
(clib_bihash_search_inline_2_with_hash)
   if (PREDICT_FALSE (BV (clib_bihash_bucket_is_empty) (b)))
 return -1;
 
-  if (PREDICT_FALSE (b->lock))
-{
-  volatile BVT (clib_bihash_bucket) * bv = b;
-  while (bv->lock)
-   CLIB_PAUSE ();
-}
+  BV (clib_bihash_lock_bucket) (b);
 
   v = BV (clib_bihash_get_value) (h, b->offset);
 
@@ -557,9 +552,11 @@ static inline int BV
(clib_bihash_search_inline_2_with_hash)
   if (BV (clib_bihash_key_compare) (v->kvp[i].key, search_key->key))
{
  *valuep = v->kvp[i];
+ BV (clib_bihash_unlock_bucket) (b);
  return 0;
}
 }
+  BV (clib_bihash_unlock_bucket) (b);
   return -1;
 }
 

Some questions regarding the change:

1. There is similar logic in clib_bihash_search_inline_with_hash. I suppose
that this change needs to be applied there as well. Am I right?

2. This patch does eliminate the race condition, but appears to introduce a
huge performance regression. The clocks in `show runtime` will double after
the change (with the 10-ops limit removed, so the test node runs
indefinitely).

Regards,
Hao Tian


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22708): https://lists.fd.io/g/vpp-dev/message/22708
Mute This Topic: https://lists.fd.io/mt/97599770/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Race condition between bihash deletion and searching - misuse or bug?

[Dave Barach]

Quick experiment: in
src/vppinfra/bihash_template.h:clib_bihash_search_inline_2_with_hash(),
replace this:

  if (PREDICT_FALSE (b->lock))
{
  volatile BVT (clib_bihash_bucket) * bv = b;
  while (bv->lock)
CLIB_PAUSE ();
}

With:

BV(clib_bihash_lock_bucket(b));

and make sure to BV(clib_bihash_unlock_bucket(b)); just prior to return 0
and return -1 in that function.

Please let me know what happens. 

Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Hao Tian
Sent: Tuesday, March 14, 2023 4:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?

Hi all,

I found that bihash might return zero'ed value (0xff's) if deletion and
searching were performed in parallel on different threads. This is
reproducible by only ~100 lines of code, from 21.06 all the way up to git
master, and on multiple machines from Coffee Lake to Tiger Lake.

The code (a plugin) and test command is shown below. Given how easy it is to
reproduce the problem, I'm not sure whether this is a bug or something
missing on my end. Any advice is welcomed. Thanks!

 bihash_race.c 

#include 
#include 
#include 

static volatile int br_run;
static clib_bihash_8_8_t br_bihash_8_8;
static int test_run_cnt[2];

static void
bihash_race_set (u64 key)
{
  clib_bihash_kv_8_8_t kv = { .key = key, .value = 1 };

  clib_bihash_add_del_8_8 (_bihash_8_8, , BIHASH_ADD); }

static void
bihash_race_del (u64 key)
{
  clib_bihash_kv_8_8_t kv = { .key = key, .value = 1 };

  clib_bihash_add_del_8_8 (_bihash_8_8, , BIHASH_DEL); }

static void
bihash_race_get (u64 key)
{
  clib_bihash_kv_8_8_t kv = { .key = key, .value = 1 };
  clib_bihash_kv_8_8_t value;

  if (!clib_bihash_search_8_8 (_bihash_8_8, , ))
    {
  if (value.value != 1)
    {
  clib_warning ("suspicious value: 0x%lx\n", value.value);
    }
    }
}

static clib_error_t *
bihash_race_init (vlib_main_t *vm)
{
  clib_bihash_init_8_8 (_bihash_8_8, "bihash_race hash", 4096, 4096 *
256);

  return 0;
}

VLIB_NODE_FN (br_test_node)
(vlib_main_t *vm, vlib_node_runtime_t *node, vlib_frame_t *frame) {
  u64 k = 0x01010101UL;

  if (!br_run || vm->thread_index == 0)
    {
  return 0;
    }

  // perform bihash set and delete for 5 times each in thread 1
  if (vm->thread_index == 1 && test_run_cnt[0] < 10)
    {
  if (test_run_cnt[1] & 1)
    bihash_race_del (k);
  else
    bihash_race_set (k);
  test_run_cnt[0]++;
  return 0;
    }

  // perform bihash lookup for 10 times in thread 2
  if (vm->thread_index == 2 && test_run_cnt[1] < 10)
    {
  bihash_race_get (k);
  test_run_cnt[1]++;
  return 0;
    }
  return 0;
}

void
bihash_race_test_reset ()
{
  memset (test_run_cnt, 0, sizeof (test_run_cnt));
  clib_warning ("== test reset =="); }

static clib_error_t *
bihash_race_test_command_fn (vlib_main_t *vm, unformat_input_t *input,
 vlib_cli_command_t *cmd) {
  u8 state = ~0;

  while (unformat_check_input (input) != UNFORMAT_END_OF_INPUT)
    {
  if (unformat (input, "on"))
    state = 1;
  else if (unformat (input, "off"))
    state = 0;
  else
    return clib_error_return (0, "invalid input");
    }

  if (state)
    {
  br_run = 1;
    }
  else
    {
  br_run = 0;
  bihash_race_test_reset ();
  vlib_cli_output (vm, "== test reset ==");
    }

  return 0;
}

VLIB_CLI_COMMAND (bihash_race_test_command, static) = {
  .path = "set bihash-race-test",
  .short_help = "set bihash-race-test |",
  .function = bihash_race_test_command_fn, };

VLIB_REGISTER_NODE (br_test_node) = {
  .name = "bihash-race-test",
  .type = VLIB_NODE_TYPE_INPUT,
  .state = VLIB_NODE_STATE_POLLING,
};

VLIB_INIT_FUNCTION (bihash_race_init);

VLIB_PLUGIN_REGISTER () = {
  .version = VPP_BUILD_VER,
  .description = "bihash race test",
};

= CMakeLists.txt =

add_vpp_plugin(bihash_race
  SOURCES
  bihash_race.c
)

= startup.conf =

unix {
  nodaemon
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid 1000
  interactive
}

cpu {
  workers 3
  main-core 1
}

dpdk {
  no-pci
}

= test command =

terminal1 # vpp -c startup.conf
terminal2 # while true; do vppctl set bihash-race-test on; sleep 1; vppctl
set bihash-race-test off; done

VPP will spit out a lot of "suspicious value: 0x" in
terminal1, while the code above never saves such value into bihash - the
value comes from the !is_add branch in clib_bihash_add_del_inline_with_hash.
Changing the memset value (and clib_bihash_is_free_* obviously) in this
branch will lead to this new value being returned.

Regards,
Hao Tian


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22703): https://lists.fd.io/g/vpp-dev/message/22703
Mute This Topic: https://lists.fd.io/mt/97599770/21656
Group 

Re: [vpp-dev] process node suspended indefinitely

[Dave Barach]

h_suspended_process (vlib_main_t * vm,
 }
   else
 {
+   if (strcmp((char *)node->name, "rtb-vpp-epoll-process") == 0) {
+   ASSERT(0);
+   }
   p->flags &= ~VLIB_PROCESS_IS_RUNNING;
   pool_put_index (nm->suspended_process_frames,
  p->suspended_process_frame_index);

 

I am not able to figure out why this process node is suspended in some 
scenarios. Can you please help me by providing some pointers to debug and 
resolve this issue. 

 

Hi Jinsh,

I applied your patch to my code. The issue is not solved with your patch. Thank 
you for helping me out.

 

Thanks and Regards,

Sudhir

 

 

On Fri, Mar 3, 2023 at 12:53 PM Sudhir CR via lists.fd.io <http://lists.fd.io>  
mailto:rtbrick@lists.fd.io> > wrote:

Hi Chetan,

In our case we are observing this issue occasionally exact steps  to recreate 
the issue are not known.

I made changes to our process node as suggested by dave and with these changes 
trying to recreate the issue.

Soon I will update my results and findings in this mail thread.

 

Thanks and Regards,

Sudhir

 

On Fri, Mar 3, 2023 at 12:37 PM chetan bhasin mailto:chetan.bhasin...@gmail.com> > wrote:

Hi Sudhir,

 

Is your issue resolved?

 

Actually we are facing same issue on vpp.2106. 

In our case "api-rx-ring" is not getting called.

in our usecase workers are calling some functions in main-thread context 
leading to RPC message and memory is allocated from api section.

This leads to Api-segment memory is used fully and leads to crash.

 

Thanks,

Chetan 

 

On Mon, Feb 20, 2023, 18:24 Sudhir CR via lists.fd.io <http://lists.fd.io>  
mailto:rtbrick@lists.fd.io> > wrote:

Hi Dave,

Thank you very much for your inputs. I will try this out and get back to you 
with the results.

 

Regards,

Sudhir 

 

On Mon, Feb 20, 2023 at 6:01 PM Dave Barach mailto:v...@barachs.net> > wrote:

Please try something like this, to eliminate the possibility that some bit of 
code is sending this process an event. It’s not a good idea to skip the 
vec_reset_length (event_data) step.

 

while (1)

{

   uword event_type, * event_data = 0;

   int i;

 

   vlib_process_wait_for_event_or_clock (vm, 1e-2 /* 10 ms */);

 

   event_type = vlib_process_get_events (vm, _data);

 

   switch (event_type) {

  case ~0: /* handle timer expirations */

   rtb_event_loop_run_once ();

   break;

 

   default: /* bug! */

   ASSERT (0);

   }

 

   vec_reset_length(event_data);

}

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Sudhir CR via lists.fd.io 
<http://lists.fd.io> 
Sent: Monday, February 20, 2023 4:02 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] process node suspended indefinitely

 

Hi Dave,
Thank you for your response and help. 

 

Please find the additional details below.

VPP Version 21.10


We are creating a process node rtb-vpp-epoll-process to handle control plane 
events like interface add/delete, route add/delete.
This process node waits for 10ms of time (Not Interested in any events ) once 
10ms is expired it will process control plane events mentioned above.

code snippet looks like below 

 

```

static uword
rtb_vpp_epoll_process (vlib_main_t *vm,
   vlib_node_runtime_t  *rt,
   vlib_frame_t *f)
{

...
...
while (1) {
vlib_process_wait_for_event_or_clock (vm, 10e-3);
vlib_process_get_events (vm, NULL);

rtb_event_loop_run_once();   < controlplane events handling 
}  
}
``` 

What we observed is that sometimes (when there is a high controlplane load like 
request to install more routes) "rtb-vpp-epoll-process" is suspended and not 
scheduled furever. this we found by using "show runtime rtb-vpp-epoll-process"  
(in "show runtime rtb-vpp-epoll-process" command output suspends counter is not 
incrementing.)

show runtime output in working case :


```
DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
192246  1.91e60.00
DBGvpp# 

DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
193634  1.89e60.00
DBGvpp# 

``` 

show runtime output in issue case :
```

DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wa

Re: [vpp-dev] FW: Bug: DHCP Client not sending DHCP REQUEST using VPP v22.02

[Dave Barach]

The dhcp client has a number of “show error” counters. Do you see any of the error counters increasing? The packet trace I’d like to see would be from “trace add  1000” … “show trace max 1000” or similar. The pcap trace implies that the dhcp offer packets are dropped, but we need to work out why… D.  From: vpp-dev@lists.fd.io  on behalf of hemant via lists.fdio Date: Thursday, March 2, 2023 at 7:13 PMTo: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] FW: Bug: DHCP Client not sending DHCP REQUEST using VPP v22.02There is something in the DHCP OFFER the client does not like and moves back to new DHCP session. Or the DHCP OFFER never made it to the client. Hemant  From: vpp-dev@lists.fd.io  On Behalf Of Thakur, AnaghaSent: Thursday, March 02, 2023 4:02 PMTo: vpp-dev@lists.fd.ioSubject: Re: [vpp-dev] FW: Bug: DHCP Client not sending DHCP REQUEST using VPP v22.02 I do see DHCP Offer in the packet tracer from the Server which I have set up on the other side.But VPP does not send any DHCP Request out, instead I always see that VPP continuously keeps sending DHCP Discovery. I have attached tx and rx pcap trace in my prevous email. Best Regards,Anagha From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Dave Barach via lists.fd.io <vpp=barachs@lists.fd.io>Sent: Thursday, 2 March 2023, 19:15To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>Subject: Re: [vpp-dev] FW: Bug: DHCP Client not sending DHCP REQUEST using VPP v22.02Do you see a response to the DHCP Discover packets?   What does the vpp packet tracer show?Thanks... Dave On Mar 2, 2023, at 7:03 AM, Thakur, Anagha <anagha.tha...@siemens.com> wrote:  Hello, I am testing DHCP client feature from VPP stack (v22.02) onto our system. My setup is: I run k8s cluster on x86 system in which I have a pod which uses VPP stack and it accesses physical NIC interface using DPDK and SR-IOV. There are two physical interfaces which we use in VPP, one of them is with static IP (eno2) and other one with as DHCP client (eno1). I expect this interface shall act as a DHCP Client and we run a DHCP server on the other end of the system. But unfortunately, the VPP does not send any DHCP REQUEST. It keeps sending DHCP DISCOVERY every interval. It receives a DHCP Offer.But VPP does not send further DHCP REQUEST to the DHCP server. I do not expect that it is a problem from lower layer and it should be an issue from VPP side. Please let me know if I need to enable any extra plugin other than the ones in the attached file.I attached pcap file recorded vpp trace of tx and rx.  Our versions are currently as follows:-> DPDK 22.03-> VPP 22.02-> VPP library 22.02 Version Information attached. plugins{  path /opt /vpp/lib/vpp_plugins  plugin default { disable }  plugin dpdk_plugin.so { enable }  plugin memif_plugin.so { enable }  plugin ping_plugin.so { enable }  plugin router_plugin.so { enable }  plugin upffp_plugin.so { enable }  plugin dhcp_plugin.so { enable }}  Commands used:set intfc VPP-N6-0 state upset int mac address eno1 00:11:22:33:44:66set dhcp client intfc eno1sh dhcp client verbose[0] VPP-N6-0 state DHCP_DISCOVER installed 0 no addresslease: lifetime:0 renewal-interval:0 expires:0.00 (now:2412.35)  retry-count:346, next-xmt:2416.87broadcast adjacency:20sh log2023/02/27 16:11:03:986 notice dhcp/client    sm active session 02023/02/27 16:11:03:986 notice dhcp/client    send: type:discover bcast:1 [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no addresslease: lifetime:0 renewal-interval:0 expires:0.00 (now:255827.12)retry-count:439, next-xmt:255827.12broadcast adjacency:112023/02/27 16:11:08:986 notice dhcp/client    sm active session 02023/02/27 16:11:08:986 notice dhcp/client    send: type:discover bcast:1 [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no addresslease: lifetime:0 renewal-interval:0 expires:0.00 (now:255832.12)retry-count:440, next-xmt:255832.12broadcast adjacency:112023/02/27 16:11:13:986 notice dhcp/client    sm active session 02023/02/27 16:11:13:986 notice dhcp/client    send: type:discover bcast:1 [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address  lease: lifetime:0 renewal-interval:0 expires:0.00 (now:255837.12)  retry-count:441, next-xmt:255837.12broadcast adjacency:112023/02/27 16:11:18:986 notice dhcp/client    sm active session 02023/02/27 16:11:18:986 notice dhcp/client    send: type:discover bcast:1 [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no addresslease: lifetime:0 renewal-interval:0 expires:0.00 (now:255842.12)retry-count:442, next-xmt:255842.12  broadcast adjacency:11show interface addresseno2 (up):   L3 172.31.254.17/29eno1 (up):host-vpp1out (up):   L3 128.0.129.144/24local0 (dn):memif0/502 (up):  Thank you in advance. Best Regards,Anagha

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22657): https://lists.fd.io/g/vpp-dev/message/22657
Mute This Topic

Re: [vpp-dev] FW: Bug: DHCP Client not sending DHCP REQUEST using VPP v22.02

[Dave Barach]

Do you see a response to the DHCP Discover packets? 

What does the vpp packet tracer show?

Thanks... Dave

> On Mar 2, 2023, at 7:03 AM, Thakur, Anagha  wrote:
> 
> 
>  
> Hello,
>  
> I am testing DHCP client feature from VPP stack (v22.02) onto our system.
>  
> My setup is: I run k8s cluster on x86 system in which I have a pod which uses 
> VPP stack and it accesses physical NIC interface using DPDK and SR-IOV. There 
> are two physical interfaces which we use in VPP, one of them is with static 
> IP (eno2) and other one with as DHCP client (eno1).
>  
> I expect this interface shall act as a DHCP Client and we run a DHCP server 
> on the other end of the system. But unfortunately, the VPP does not send any 
> DHCP REQUEST. It keeps sending DHCP DISCOVERY every interval. It receives a 
> DHCP Offer.
> But VPP does not send further DHCP REQUEST to the DHCP server. I do not 
> expect that it is a problem from lower layer and it should be an issue from 
> VPP side. Please let me know if I need to enable any extra plugin other than 
> the ones in the attached file.
> I attached pcap file recorded vpp trace of tx and rx.
>  
>  
> Our versions are currently as follows:
> -> DPDK 22.03
> -> VPP 22.02
> -> VPP library 22.02
>  
> Version Information attached.
>  
> plugins
> {
>   path /opt /vpp/lib/vpp_plugins
>   plugin default { disable }
>   plugin dpdk_plugin.so { enable }
>   plugin memif_plugin.so { enable }
>   plugin ping_plugin.so { enable }
>   plugin router_plugin.so { enable }
>   plugin upffp_plugin.so { enable }
>   plugin dhcp_plugin.so { enable }
> }
>  
>  
> Commands used:
> set intfc VPP-N6-0 state up
> set int mac address eno1 00:11:22:33:44:66
> set dhcp client intfc eno1
> sh dhcp client verbose
> [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address
> lease: lifetime:0 renewal-interval:0 expires:0.00 (now:2412.35)
>   retry-count:346, next-xmt:2416.87
> broadcast adjacency:20
> sh log
> 2023/02/27 16:11:03:986 notice dhcp/clientsm active session 0
> 2023/02/27 16:11:03:986 notice dhcp/clientsend: type:discover bcast:1 
> [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address
> lease: lifetime:0 renewal-interval:0 expires:0.00 (now:255827.12)
> retry-count:439, next-xmt:255827.12
> broadcast adjacency:11
> 2023/02/27 16:11:08:986 notice dhcp/clientsm active session 0
> 2023/02/27 16:11:08:986 notice dhcp/clientsend: type:discover bcast:1 
> [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address
> lease: lifetime:0 renewal-interval:0 expires:0.00 (now:255832.12)
> retry-count:440, next-xmt:255832.12
> broadcast adjacency:11
> 2023/02/27 16:11:13:986 notice dhcp/clientsm active session 0
> 2023/02/27 16:11:13:986 notice dhcp/clientsend: type:discover bcast:1 
> [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address
>   lease: lifetime:0 renewal-interval:0 expires:0.00 
> (now:255837.12)
>   retry-count:441, next-xmt:255837.12
> broadcast adjacency:11
> 2023/02/27 16:11:18:986 notice dhcp/clientsm active session 0
> 2023/02/27 16:11:18:986 notice dhcp/clientsend: type:discover bcast:1 
> [0] VPP-N6-0 state DHCP_DISCOVER installed 0 no address
> lease: lifetime:0 renewal-interval:0 expires:0.00 (now:255842.12)
> retry-count:442, next-xmt:255842.12
>   broadcast adjacency:11
> show interface address
> eno2 (up):
>L3 172.31.254.17/29
> eno1 (up):
> host-vpp1out (up):
>L3 128.0.129.144/24
> local0 (dn):
> memif0/502 (up):
>  
>  
> Thank you in advance.
>  
> Best Regards,
> Anagha
>  
>  
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22652): https://lists.fd.io/g/vpp-dev/message/22652
Mute This Topic: https://lists.fd.io/mt/97336867/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] process node suspended indefinitely

[Dave Barach]

Please try something like this, to eliminate the possibility that some bit of 
code is sending this process an event. It’s not a good idea to skip the 
vec_reset_length (event_data) step.

 

while (1)

{

   uword event_type, * event_data = 0;

   int i;

 

   vlib_process_wait_for_event_or_clock (vm, 1e-2 /* 10 ms */);

 

   event_type = vlib_process_get_events (vm, _data);

 

   switch (event_type) {

  case ~0: /* handle timer expirations */

   rtb_event_loop_run_once ();

   break;

 

   default: /* bug! */

   ASSERT (0);

   }

 

   vec_reset_length(event_data);

}

 

From: vpp-dev@lists.fd.io  On Behalf Of Sudhir CR via 
lists.fd.io
Sent: Monday, February 20, 2023 4:02 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] process node suspended indefinitely

 

Hi Dave,
Thank you for your response and help. 

 

Please find the additional details below.

VPP Version 21.10


We are creating a process node rtb-vpp-epoll-process to handle control plane 
events like interface add/delete, route add/delete.
This process node waits for 10ms of time (Not Interested in any events ) once 
10ms is expired it will process control plane events mentioned above.

code snippet looks like below 

 

```

static uword
rtb_vpp_epoll_process (vlib_main_t *vm,
   vlib_node_runtime_t  *rt,
   vlib_frame_t *f)
{

...
...
while (1) {
vlib_process_wait_for_event_or_clock (vm, 10e-3);
vlib_process_get_events (vm, NULL);

rtb_event_loop_run_once();   < controlplane events handling 
}  
}
``` 

What we observed is that sometimes (when there is a high controlplane load like 
request to install more routes) "rtb-vpp-epoll-process" is suspended and not 
scheduled furever. this we found by using "show runtime rtb-vpp-epoll-process"  
(in "show runtime rtb-vpp-epoll-process" command output suspends counter is not 
incrementing.)

show runtime output in working case :


```
DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
192246  1.91e60.00
DBGvpp# 

DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
193634  1.89e60.00
DBGvpp# 

``` 

show runtime output in issue case :
```

DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
 81477  7.08e60.00
DBGvpp# show runtime rtb-vpp-epoll-process
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call  
rtb-vpp-epoll-process   any wait 0   0  
 81477  7.08e60.00

```

Other process nodes like lldp-process, ip4-neighbor-age-process, ip6-ra-process 
running without any issue. only "rtb-vpp-epoll-process" process node suspended 
forever. 

 

Please let me know if any additional information is required.

Hi Jinsh,
Thanks for pointing me to the issue you faced. The issue I am facing looks 
similar.
I will verify with the given patch.


Thanks and Regards,

Sudhir

 

On Sun, Feb 19, 2023 at 6:19 AM jinsh11 mailto:jins...@chinatelecom.cn> > wrote:

HI：



*   I have the same problem，

bfd process node stop running. I raised this issue,

https://lists.fd.io/g/vpp-dev/message/22380
I think there is a problem with the porcess scheduling module when using the 
time wheel.





 

NOTICE TO RECIPIENT This e-mail message and any attachments are confidential 
and may be privileged. If you received this e-mail in error, any review, use, 
dissemination, distribution, or copying of this e-mail is strictly prohibited. 
Please notify us immediately of the error by return e-mail and please delete 
this message from your system. For more information about Rtbrick, please visit 
us at www.rtbrick.com  


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22605): https://lists.fd.io/g/vpp-dev/message/22605
Mute This Topic: https://lists.fd.io/mt/97032803/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] process node suspended indefinitely

[Dave Barach]

Process is a bit of a misnomer, “cooperative multitasking thread” would be more 
accurate. Src/vlib/main.c makes no effort to interrupt process nodes. If a 
process runs forever vpp will have a bad day.

 

Recitations: which version of vpp is involved? Please send “show run” output 
for the process node in question.

 

The process might be waiting on an event which never happens, or for the clock 
to reach a time so far in the future it won’t happen in one’s lifetime. Worse 
luck might involve memory corruption or an issue with the timer wheel code.

 

HTH... Dave 

 

From: vpp-dev@lists.fd.io  On Behalf Of Sudhir CR via 
lists.fd.io
Sent: Friday, February 17, 2023 12:12 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] process node suspended indefinitely

 

Hi Team,

We have a process node. which we will use to do some control plane related 
activity. Sometimes we observe that this process node is suspended  
indefinitely.

 

I know that if any process node is taking Unreasonably long time such nodes 
will  not be scheduled further. But not able to figure out in code where this 
is done.

 

Can anyone point me to the code where we are tracking time taken by each 
process node and suspend indefinitely if it is consuming more time.

 

Thanks and regards,

Sudhir

 

NOTICE TO RECIPIENT This e-mail message and any attachments are confidential 
and may be privileged. If you received this e-mail in error, any review, use, 
dissemination, distribution, or copying of this e-mail is strictly prohibited. 
Please notify us immediately of the error by return e-mail and please delete 
this message from your system. For more information about Rtbrick, please visit 
us at www.rtbrick.com  


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22601): https://lists.fd.io/g/vpp-dev/message/22601
Mute This Topic: https://lists.fd.io/mt/97032803/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] sigsegv and its handler

[Dave Barach]

This seems consistent with a SIGSEGV compounded by a worker-thread stack 
overflow situation. In hopes of obtaining a clean core file, you might want to 
modify the SIGSEGV handler to simply abort() instead of trying to write a 
post-mortem API dump, syslog’ing a backtrace, etc.

 

Best of luck with it.  

 

From: vpp-dev@lists.fd.io  On Behalf Of Stanislav Zaikin
Sent: Wednesday, February 1, 2023 6:17 AM
To: vpp-dev 
Subject: [vpp-dev] sigsegv and its handler

 

Hello folks,

 

I've been experiencing rare crashes (one crash in 3 months or so), it looks 
like the heap is corrupted somehow. Sometimes, the trace shows very unexpected 
nodes (like ip6-map-t although I don't configure any ipv6 map) or sometimes 
it's just a crash inside ip4-rewrite-node.

 

After a look I found that last 2 crashes occured in the same way:

1. vnet_feature_arc_start_w_cfg_index or vnet_feature_arc_start call

2. vnet_get_config_data call

 

But then VPP received and handled a SIGSEGV signal. It completely broke the 
stack trace in the core dump (for the corresponding worker):

#0  0x7f44fa0812c6 in __GI_epoll_pwait (epfd=8, events=0x7f44babe52d8, 
maxevents=, timeout=9, set=0x7f44fa5c66f8 
) at 
../sysdeps/unix/sysv/linux/epoll_pwait.c:42
#1  0x00089f6fab2b in ?? ()
#2  0x7f44babe52d8 in ?? ()
#3  0x00090100 in ?? ()
#4  0x7f44fa5c66f8 in _vlib_init_function_init_linux_epoll_input_init () 
from /lib/x86_64-linux-gnu/libvlib.so.22.10.0
#5  0x in ?? ()

 

So, I can't analyze the core dump. Any ideas on how to catch this crash 
correctly? Disable receiving SIGSEGV? Or is there a way to restore the original 
stack trace of the worker?

 

For the reference, stack traces from syslog:

vnet[2856086]: received signal SIGSEGV, PC 0x7f44b76dbee3, faulting address 
0xb0040114
vnet[2856086]: #0  0x7f44fa43885b 0x7f44fa43885b (unix_signal_handler+379)
vnet[2856086]: #1  0x7f44fa34f3c0 0x7f44fa34f3c0 (__funlockfile)
vnet[2856086]: #2  0x7f44b76dbee3 0x7f44b76dbee3 (ip6_map_t+675)
vnet[2856086]: #3  0x7f44fa3c86fb vlib_worker_loop + 0x1b3b
vnet[2856086]: #4  0x7f44fa41aafa vlib_worker_thread_fn + 0xaa
vnet[2856086]: #5  0x7f44fa414e01 vlib_worker_thread_bootstrap_fn + 0x51
vnet[2856086]: #6  0x7f44fa343609 start_thread + 0xd9
vnet[2856086]: #7  0x7f44fa081163 clone + 0x43

vnet[944491]: received signal SIGSEGV, PC 0x7faf922ca6ae, faulting address 
0x7fb3519530fc
vnet[944491]: #0  0x7faf9102785b 0x7faf9102785b
vnet[944491]: #1  0x7faf90f3e3c0 0x7faf90f3e3c0
vnet[944491]: #2  0x7faf922ca6ae ip4_rewrite_node_fn_skx + 0x149e
vnet[944491]: #3  0x7faf90fb76fb vlib_worker_loop + 0x1b3b
vnet[944491]: #4  0x7faf91009afa vlib_worker_thread_fn + 0xaa
vnet[944491]: #5  0x7faf91003e01 vlib_worker_thread_bootstrap_fn + 0x51
vnet[944491]: #6  0x7faf90f32609 start_thread + 0xd9
vnet[944491]: #7  0x7faf90c70163 clone + 0x43

 

Line information:

Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 
0x7f44b76dbee3  and ends at 0x7f44b76dbee7 .

 

Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 
0x7f44fb6db6ae  and ends at 0x7f44fb6db6b1 
.

 

-- 

Best regards
Stanislav Zaikin


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22533): https://lists.fd.io/g/vpp-dev/message/22533
Mute This Topic: https://lists.fd.io/mt/96673497/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Possible VPP deadlock

[Dave Barach]

It looks like the root-cause is a corrupted heap. See also 
mspace_free()->check_top_chunk()->do_check_top_chunk(). One of the assertions 
is failing.

 

Once the heap is pickled, all bets are off in terms of getting a useful API 
trace. 

 

Since you have a couple of (possibly) useful post-mortem dumps, the first step 
would be to figure out why printing the api traces causes a NULL pointer 
dereference.

 

It should be comparatively simple to work out the NULL pointer dereference in 
the api trace printer. You can binary search for the offending message, walk 
through vl_msg_print_trace(...) and figure out what’s going on. It’s likely 
that the message in question simply doesn’t have a print function. See 
src/vlibmemory/vlib_api_cli.c:api_trace_command_fn() for details. In 
particular, “first” and “last” describe which messages should be printed (or 
replayed).

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Pim van Pelt via 
lists.fd.io
Sent: Sunday, January 8, 2023 1:24 PM
To: vpp-dev 
Subject: [vpp-dev] Possible VPP deadlock

 

Hoi,

 

I've had a few instances of a recent VPP hanging - API and CLI go unresponsive, 
forwarding stops (at least, I think), but the worker threads are still 
consuming CPU.

Attaching GDB, I see the main thread is doing the following:

(gdb) bt

#0  0x7f5f6f8f271b in sched_yield () at 
../sysdeps/unix/syscall-template.S:78

#1  0x7f5f6fb3df8b in spin_acquire_lock (sl=) at 
/home/pim/src/vpp/src/vppinfra/dlmalloc.c:468

#2  mspace_malloc (msp=0x130048040, bytes=72) at 
/home/pim/src/vpp/src/vppinfra/dlmalloc.c:4351

#3  0x7f5f6fb66f81 in mspace_memalign (msp=0x130048040, 
alignment=, bytes=72) at 
/home/pim/src/vpp/src/vppinfra/dlmalloc.c:4667

#4  clib_mem_heap_alloc_inline (heap=, size=72, align=, os_out_of_memory_on_failure=1) at 
/home/pim/src/vpp/src/vppinfra/mem_dlmalloc.c:608

#5  clib_mem_heap_alloc_aligned (heap=, size=72, align=8) at 
/home/pim/src/vpp/src/vppinfra/mem_dlmalloc.c:664

#6  0x7f5f6fba5157 in _vec_alloc_internal (n_elts=64, attr=) 
at /home/pim/src/vpp/src/vppinfra/vec.c:35

#7  0x7f5f6fb848c8 in _vec_resize (vp=, n_add=64, hdr_sz=0, 
align=8, elt_sz=) at /home/pim/src/vpp/src/vppinfra/vec.h:256

#8  serialize_vector_write (m=, s=0x7f5f0dbfebc0) at 
/home/pim/src/vpp/src/vppinfra/serialize.c:908

#9  0x7f5f6fb843c1 in serialize_write_not_inline (m=0x7f5f0dbfeb60, 
s=, n_bytes_to_write=4, flags=) at 
/home/pim/src/vpp/src/vppinfra/serialize.c:734

#10 0x7f5f6fe5a053 in serialize_stream_read_write (header=0x7f5f0dbfeb60, 
s=, n_bytes=4, flags=2) at 
/home/pim/src/vpp/src/vppinfra/serialize.h:140

#11 serialize_get (m=0x7f5f0dbfeb60, n_bytes=4) at 
/home/pim/src/vpp/src/vppinfra/serialize.h:180

#12 serialize_integer (m=0x7f5f0dbfeb60, x=, n_bytes=4) at 
/home/pim/src/vpp/src/vppinfra/serialize.h:187

#13 vl_api_serialize_message_table (am=0x7f5f6fe66258 , 
vector=) at /home/pim/src/vpp/src/vlibapi/api_shared.c:210

#14 0x7f5f6fe5a715 in vl_msg_api_trace_save (am=0x130048040, 
which=, fp=0x13f0690, is_json=27 '\033') at 
/home/pim/src/vpp/src/vlibapi/api_shared.c:410

#15 0x7f5f6fe5c0ea in vl_msg_api_post_mortem_dump () at 
/home/pim/src/vpp/src/vlibapi/api_shared.c:880

#16 0x004068c6 in os_panic () at 
/home/pim/src/vpp/src/vpp/vnet/main.c:415

#17 0x7f5f6fb3feed in mspace_free (msp=0x130048040, mem=) at 
/home/pim/src/vpp/src/vppinfra/dlmalloc.c:2954

#18 0x7f5f6fb6bf8c in clib_mem_heap_free (heap=0x0, p=) at 
/home/pim/src/vpp/src/vppinfra/mem_dlmalloc.c:768

#19 clib_mem_free (p=) at 
/home/pim/src/vpp/src/vppinfra/mem_dlmalloc.c:774

#20 0x7f5f2fa32b40 in ?? ()

#21 0x7f5f3302f848 in ?? ()

#22 0x in ?? ()

 

When I kill VPP, sometimes an api_post_mortem is emitted (although most of the 
time they are empty), but subsequently trying to dump it, makes VPP crash -

 

-rw--- 1 ipng ipng 35437 Jan  8 19:08 api_post_mortem.76724

-rw--- 1 ipng ipng 35368 Jan  8 19:08 api_post_mortem.76842

-rw--- 1 ipng ipng 0 Jan  8 19:08 api_post_mortem.76978

-rw--- 1 ipng ipng 0 Jan  8 19:08 api_post_mortem.84008

 

#0  0x in ?? ()

#1  0x77fada5f in vl_msg_print_trace (msg=0x7fff9db73bd8 "", 
ctx=0x7fff53b62ca0) at /home/pim/src/vpp/src/vlibmemory/vlib_api_cli.c:693

#2  0x766a55bb in vl_msg_traverse_trace (tp=0x7fff9b4e7998, 
fn=0x77fad790 , ctx=0x7fff53b62ca0)

at /home/pim/src/vpp/src/vlibapi/api_shared.c:321

#3  0x77fab854 in api_trace_command_fn (vm=0x7fff96000700, 
input=0x7fff53b62f30, cmd=)

at /home/pim/src/vpp/src/vlibmemory/vlib_api_cli.c:727

#4  0x7647fdad in vlib_cli_dispatch_sub_commands (vm=0x7fff96000700, 
cm=, input=0x7fff53b62f30, 

parent_command_index=) at 
/home/pim/src/vpp/src/vlib/cli.c:650

#5  0x7647fb91 in vlib_cli_dispatch_sub_commands (vm=0x7fff96000700, 
cm=, input=0x7fff53b62f30, 

parent_command_index=) at 

Re: [vpp-dev] Outdated home gateway script for NAT?

[Dave Barach]

The “service restart isc-dhcp-server” command is a hack which only knows how to 
restart the isc-dhcp-server, not dnsmasq. 

 

You’ll need to tinker with it to restart dnsmasq, which almost certainly needs 
to deal with the lstack interface.

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of pepijn de vos
Sent: Sunday, December 25, 2022 12:49 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Outdated home gateway script for NAT?

 

Hi Dave,

Works!
I modified the .gate file to define TRUNKHW (the actual hardware interface) and 
VLAN and updated TRUNK to be the subinterface.
Then I added a few lines to create the subinterface, and the rest of the script 
now automatically referred to the subinterface.
So at least the tap interface, wan dhcp client, and the nat44 setup work with 
the subinterface.
I'm not using any of the other goodies for now, since I want to keep it simple 
and understandable.
I'm using dnsmasq for the DHCP and DNS server, I could add my config to the 
docs if that would be useful.

Oh reminds me, I also got an input error from the service restart command that 
supposedly restarts the DHCP server.
Not sure why that's there, and if you should be able to execute arbitrary shell 
commands, or there is some service plugin I did not load.
I did find that dnsmasq doesn't like it if you tell it to only bind to lstack 
before vpp has started for obvious reasons, but the default behavior of binding 
to all interfaces and rejecting the ones that are not selected works like a 
treat.
(this seems fine since the kernel doesn't know about the WAN interface anyway)

Regards,
Pepijn 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22387): https://lists.fd.io/g/vpp-dev/message/22387
Mute This Topic: https://lists.fd.io/mt/95859254/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Outdated home gateway script for NAT?

[Dave Barach]

I think that you just need to create an L3 vlan subinterface:

 

vpp# create sub-interface  300

 

At that point, .300 should be an L3 subinterface which will 
strip vlan tag 300 for RX packets, and add vlan tag 300 for TX packets. Strikes 
me that that’s exactly what you need. 

 

if =GigabitEthernet3/0/0, setting TRUNK_PORT to 
GigabitEthernet3/0/0.300 and inhaling the rest of the configuration MAY just 
work. I’ve never tested the various NAT flavors, the DNS resolver, etc. to see 
if the code truly works with vlan subinterfaces.

 

Let me know what happens. I’ve never constructed a suitable test topology for 
this use case, so it may take some doing to fix issues.  

 

HTH... Dave

 

 

From: vpp-dev@lists.fd.io  On Behalf Of pepijn de vos
Sent: Sunday, December 25, 2022 11:30 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Outdated home gateway script for NAT?

 

Hi Dave,

Thanks a lot of the update, I have managed to get it to work now, at least as a 
secondary router behind my ISP router.
My ISP wants the WAN port to use VLAN 300, and I can't figure out how to do 
that.

I've tried to push the vlan tag on the outward port 

set int l2 tag-rewrite $(TRUNK) push dot1q 300

and I tried creating a subinterface and binding nat44 to that 

create sub-interfaces $(TRUNK) 300 default

set int state $(TRUNK).300 up
set interface nat44 in bvi0 out $(TRUNK).300

and tried the reverse on the bvi0 interface.
I might be missing the correct commands by a millimeter or a kilometer, but I'm 
not getting an IP on the WAN.

TBH I did not copy most of the new additions because I had to google what some 
of them even stand for.
Maybe once I got this all set up I should make a PR to add some comments and 
instructions for beginners like me on what some of these commands do and what 
they are for.

Cheers,
Pepijn 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22385): https://lists.fd.io/g/vpp-dev/message/22385
Mute This Topic: https://lists.fd.io/mt/95859254/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Outdated home gateway script for NAT?

[Dave Barach]

I've updated the doc, please see https://gerrit.fd.io/r/c/vpp/+/37859

HTH... Dave

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22383): https://lists.fd.io/g/vpp-dev/message/22383
Mute This Topic: https://lists.fd.io/mt/95859254/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Outdated home gateway script for NAT?

[Dave Barach]

Thanks for the report. I’ll update the doc…

> On Dec 24, 2022, at 3:45 AM, pepijn de vos  wrote:
> 
> 
> Hello,
> 
> I'm quite new to VPP and trying to follow the "VPP as a Home Gateway" setup.
> After following the installation instructions and copying the configuration 
> files, NAT does not seem to be working.
> When I enabled NAT44 it gave an outright error: nat44: unknown input `enable 
> users 50 user-sessions ...'
> I then tried to change that to "nat44 plugin enable" as an educated guess, 
> and also tried to enable CNAT instead as the example does.
> 
> In both cases the result is the same:
> The WAN port gets an IP, the LAN port hands out IPs, and I can ping 
> 192.168.5.2 from the LAN port.
> But I can not ping 192.168.5.1 or the rest of the internet from either the 
> router itself or the LAN port.
> What I CAN do is enable the ping plugin and ping 8.8.8.8 from vppctl.
> So it seems to me like the LAN and WAN sides are both working as intended, 
> but NAT isn't working.
> 
> I'm not really sure how to go ahead debugging this issue.
> Also apologies if this is too much of a "user" question for a "dev" mailing 
> list, but I did not find anything else, and it seems like the docs are at 
> least somewhat wrong/outdated.
> 
> Regards,
> Pepijn
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22382): https://lists.fd.io/g/vpp-dev/message/22382
Mute This Topic: https://lists.fd.io/mt/95859254/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Bug report - IP6 ND RA default route disappear from host device

[Dave Barach]

Merged... This patch addresses similar issues with iOS devices which appear to 
pay attention to the router flag...

 

Thanks... Dave  

 

From: vpp-dev@lists.fd.io  On Behalf Of Petr Boltík
Sent: Sunday, November 6, 2022 4:09 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Bug report - IP6 ND RA default route disappear from host 
device

 

Hi Matt,

 

Thank you. I can confirm that your fix works. Now I can continue to deploy ipv6 
using kea dhcpv6 (without static configuration).

 

Best regards

Petr B.

 

ne 6. 11. 2022 v 0:13 odesílatel Petr Boltík via lists.fd.io 
  mailto:gmail@lists.fd.io> > napsal:

Hi Matt,

 

Than you so much. I will test it as soon as possible.

 

Petr

 

Dne so 5. 11. 2022 21:44 uživatel Matthew Smith via lists.fd.io 
  mailto:netgate@lists.fd.io> > napsal:

Hi Petr,

 

You didn't miss any configuration. I don't see any place where the router flag 
is set on an NA in current VPP master branch code.

 

Can you test with https://gerrit.fd.io/r/c/vpp/+/37582 applied and see if it 
addresses the issue?

 

-Matt

 

 

 

 

On Fri, Nov 4, 2022 at 1:49 PM Petr Boltík mailto:petr.bol...@gmail.com> > wrote:

Hi,

 

Thanks for your reply. 

 

I did a packet capture using Wireshark to compare RA from the 
VPP/MikroTik/Radvd. There is no problem with routing advertisements from VPP, 
but with Neighbor Advertisement when RA is enabled. ICMP v6 flag is not set 
correctly - The Router flag is NOT set on the VPP side. Debian 11 ignores this, 
Windows and a few others remove the default gateway after receiving this 
neighbor advertisement. Wireshark .pcapng in the link.

 

I use the Kea6 dhcp6 server for prefix delegation + VPP for RA (not using radvd 
- only for testing). Many users want to use VPP as a home gateway and IPv6 RA 
not working correctly with various end-user devices (like windows for this 
testing scenario).

 

VPP RA+ND - line 914

MikroTik RA+ND - line 819

 

https://easyupload.io/m/xwvqjj

 

If I missed something in the configuration of VPP, please let me know. I did 
not find any relevant CLI 

 

Best regards

Petr

 

 

pá 4. 11. 2022 v 13:25 odesílatel Benoit Ganne (bganne) via lists.fd.io 
  mailto:cisco@lists.fd.io> > napsal:

Hi Petr,

Unfortunately I can't confirm the issue, but I do not think it is a very 
commonly tested scenario so it is not really surprising...
What could help understand the issue would be if you could capture the RA 
traffic in both scenarios (VPP vs radvd) so we can compare.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io     > On Behalf Of Petr Boltík
> Sent: Friday, November 4, 2022 12:50
> To: vpp-dev mailto:vpp-dev@lists.fd.io> >
> Subject: Re: [vpp-dev] Bug report - IP6 ND RA default route disappear from
> host device
> 
> Hi all,
> 
> Can someone please confirm this VPP IP6 RA issue? Any idea is welcome. I
> already tested the latest VPP build v23.02-rc0~96-ge69d97438~b598 with no
> success. Installed default IP6 GW on Windows7/10/UBNTairOS disappeared
> after a short time. Thanks
> 
> Best regards
> Petr B.
> 
> pá 28. 10. 2022 v 18:37 odesílatel Petr Boltík   
>  > > napsal:
> 
> 
>   Hi all,
> 
>   I have discovered the problem with IP6 ND RA receiving side - it
> can be observed on Windows 10/7/UBNT airos8 and some others. Issue not
> observed on the Debian 11+nmcli. Configuration is pretty straightforward.
> Tested with VPP 22.06, 22.10. Issue persists. VPP configuration is the
> default, tested on APU4D4 and a few others. No linuxcp/nl is used.
> 
>   1. configure VPP:
> 
>   set interface ip address GigabitEthernet3/0/0 2a01:500::1/64
>   set interface state GigabitEthernet3/0/0 up
>   create loopback interface
>   set interface state loop0 up
>   set interface ip address loop0 2a01:400::1/64
>   ip6 nd GigabitEthernet3/0/0 prefix 2a01:500::/64 default
>   ip6 nd GigabitEthernet3/0/0 no ra-suppress
> 
> 
> 
>   vpp# show version
> 
>   vpp v22.10-release built by root on 89a4591888eb at 2022-10-
> 26T14:00:30
> 
> 
>   2. connect host Windows7/10/ubnt to the GigabitEthernet3/0/0 and
> you can observe weird behavior
>   - RA from VPP is received, IP6 address is installed. Icmp echo to
> the VPP link local address and configured 2a01:500::1 works.
>   - RA from VPP is received, IP6 default route is installed and
> works. Icmp echo to the 2a01:400::1 works.
> 
> 
>   Issue:  After stopping all icmp echo for a few seconds/minutes, IP6
> default route is removed from the host system, and the path to the
> 2a01:400::1 is unknown for the host. The default route is removed - the
> host device ignores ra-lifetime.
> 
>   LinuxCP/NL + RADVD sollution 

Re: [vpp-dev] maintainer's email

[Dave Barach]

I cleaned up my Linux Foundation profile. Hopefully the problem won't recur. 
Thanks for the report... Dave Barach

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22129): https://lists.fd.io/g/vpp-dev/message/22129
Mute This Topic: https://lists.fd.io/mt/94811012/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] pcap_write error: bad address #pcap

[Dave Barach]

Use gdb to inspect the pcap_main_t. In particular, determine 
vec_len(pm->pcap_data) [“(gdb) vl(pm->pcap_data)”] and pm->n_pcap_data_written. 
For reasonable N pcap_write(...) is known to work.

 

D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of aihua1...@163.com
Sent: Sunday, October 16, 2022 11:23 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] pcap_write error: bad address #pcap

 

dear all:
pcap_write,use type int n;
if  n is negative。  int n = vec_len (pm->pcap_data) - 
pm->n_pcap_data_written;
write func will failed，errno = 14.
n = write (pm->file_descriptor, 

 vec_elt_at_index (pm->pcap_data, pm->n_pcap_data_written),

n); 
int   cast   to  size_t  may case  some overflow？ 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22041): https://lists.fd.io/g/vpp-dev/message/22041
Mute This Topic: https://lists.fd.io/mt/94377467/21656
Mute #pcap:https://lists.fd.io/g/vpp-dev/mutehashtag/pcap
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vlib_log assert in dataplane workers

[Dave Barach]

A single printf() costs more clock cycles than processing a packet through
the entire forwarding graph. It's not OK to call vlib_log() in data plane
code.  

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of Vadim Platonov
via lists.fd.io
Sent: Friday, September 2, 2022 8:14 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_log assert in dataplane workers

 

Hi,

 

Could you explain the reason of the assert
https://github.com/FDio/vpp/blob/master/src/vlib/log.c#L146?

Is this the performance reason?

Could we use vlib_log on dataplane workers?

 

Best Regards,

 

Vadim Platonov

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21845): https://lists.fd.io/g/vpp-dev/message/21845
Mute This Topic: https://lists.fd.io/mt/93417565/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vlib buffer allocate/free consumes too many CPU cycles

[Dave Barach]

+1, Ben has it exactly right... Dave

On 8/23/22, 4:04 AM, "Benoit Ganne (bganne) via lists.fd.io" 
 wrote:

vlib_buffer_validate_alloc_free() should only be called with debug builds 
to debug buffer allocation issues.
Debug builds are slow, because there is no optimizations and lots of 
additional checks.
Please make sure you are using a release build before benchmarking (eg. 
make build-release).

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of zheng jie
> Sent: Tuesday, August 23, 2022 9:23
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] vlib buffer allocate/free consumes too many CPU cycles
> 
> hi team,
> 
> recently I am doing plugin dev with VPP,  I found all threads are spending
> too many CPU cycles with locking/unlocking (with one numa
> node)buffer_main's buffer_known_hash_lockp,  it hinders burst performance.
> 
> ```
> +6.00%  vpp_wk_4 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +5.33%  vpp_wk_7 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +5.29%  vpp_wk_9 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +5.18%  vpp_wk_2 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +5.05%  vpp_wk_0 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.95%  vpp_wk_10libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.92%  vpp_wk_6 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.90%  vpp_wk_3 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.63%  vpp_wk_8 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.41%  vpp_wk_5 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.33%  vpp_wk_1 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +4.24%  vpp_wk_11libvlib.so.22.02.0[.]
> clib_spinlock_lock
> +2.27%  vpp_main libvlib.so.22.02.0[.] dispatch_node
> +0.89%  vpp_main libvlib.so.22.02.0[.]
> vlib_main_or_worker_loop
> +0.85%  vpp_main libvlib.so.22.02.0[.] vlib_get_node
> +0.83%  vpp_wk_11libvlib.so.22.02.0[.] vlib_frame_free
> +0.78%  vpp_wk_1 libvlib.so.22.02.0[.] vlib_frame_free
> +0.65%  vpp_wk_5 libvlib.so.22.02.0[.] vlib_frame_free
> +0.51%  vpp_main vcgnat_dp_plugin.so   [.]
> node_channel_tx_process
> 
> 
> ```
> 
> the calling graph:
> 
> -5.33%  vpp_wk_7 libvlib.so.22.02.0[.]
> clib_spinlock_lock
>- clib_spinlock_lock
>   - 4.89% vlib_buffer_is_known
>  - vlib_buffer_validate_alloc_free
> + 1.94% vlib_buffer_alloc_from_pool
> + 1.45% vlib_buffer_pool_put
> + 1.42% vlib_buffer_alloc_from_pool
> -5.29%  vpp_wk_9 libvlib.so.22.02.0[.]
> clib_spinlock_lock
>- clib_spinlock_lock
>   - 4.89% vlib_buffer_is_known
>  - vlib_buffer_validate_alloc_free
> + 2.14% vlib_buffer_alloc_from_pool
> + 1.40% vlib_buffer_alloc_from_pool
> + 1.28% vlib_buffer_pool_put
> +5.18%  vpp_wk_2 libvlib.so.22.02.0[.]
> clib_spinlock_lock
> -5.05%  vpp_wk_0 libvlib.so.22.02.0[.]
> clib_spinlock_lock
>- clib_spinlock_lock
>   - 4.57% vlib_buffer_is_known
>  - vlib_buffer_validate_alloc_free
> + 2.25% vlib_buffer_alloc_from_pool
> + 1.20% vlib_buffer_pool_put
> + 1.03% vlib_buffer_alloc_from_pool
> 
> 
> 
> thanks,
> Looking forward to your help.
> 







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21813): https://lists.fd.io/g/vpp-dev/message/21813
Mute This Topic: https://lists.fd.io/mt/93199622/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Free a vlib buffer from out a VPP worker thread

[Dave Barach]

Short answer: yes. Here's an example of how to start a foreign thread taken
from the [golang dialect] g2 viewer plugin (*):

 

/* *INDENT-OFF* */

VLIB_REGISTER_THREAD (ego_g2_thread_reg, static) = {

  .name = "g2-thread",

  .short_name = "g2",

  .function = ego_g2_thread_fn,

  .use_pthreads = 1,

  .no_data_structure_clone = 1,

  .fixed_count = 1,

  .count = 1,

};

/* *INDENT-ON* */

 

In this case, we don't clone the required data structures to free a buffer.
If you remove the initialization ".no_data_structure_clone=1", you should be
all set. Check out ".use_pthreads = 1" in src/vlib/threads.c, etc. to see if
that's what you want. 

 

HTH... Dave 

 

(*) See https://github.com/dbarach/vpp-event-viewer.git if you're interested
in the g2 viewer.

 

 

From: vpp-dev@lists.fd.io  On Behalf Of Simon Barber
via lists.fd.io
Sent: Friday, August 12, 2022 9:30 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Free a vlib buffer from out a VPP worker thread

 

Dave,

 

Does VPP support the concept of  additional  threads that are spawned from
within a  plugin, lets call  them 'external threads',  and the  allocation
of a  vlib_main_t / vlib_buffer_pool_thread_t for these external threads, or
should all interactions such as freeing a buffer, be performed from within
the  worker thread that the buffer was originally presented to the plugin
on.. 

 

Cheers

 

Simon

 

 

 

 

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: Thursday, August 11, 2022 12:07 PM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: [EXTERNAL] Re: [vpp-dev] Free from a vlib buffer from out a VPP
worker thread

 


You don't often get email from vpp=barachs@lists.fd.io
<mailto:vpp=barachs@lists.fd.io> . Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification> 



As long as the thread has an associated vlib_main_t /
vlib_buffer_pool_thread_t not accidentally shared with another thread, you
shouldn't have any problems... 

 

FWIW... Dave

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Simon Barber via lists.fd.io
Sent: Thursday, August 11, 2022 6:42 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: [vpp-dev] Free from a vlib buffer from out a VPP worker thread

 

Hi,

 

Does anybody anticipate any issues calling  vlib_buffer_free_one to free a
buffer when running on a thread that is not registered as a VPP worker
thread.

 

Initial testing indicates that it works.

 

Regards

 

Simon

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21798): https://lists.fd.io/g/vpp-dev/message/21798
Mute This Topic: https://lists.fd.io/mt/92979452/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Free from a vlib buffer from out a VPP worker thread

[Dave Barach]

As long as the thread has an associated vlib_main_t /
vlib_buffer_pool_thread_t not accidentally shared with another thread, you
shouldn't have any problems... 

 

FWIW... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Simon Barber
via lists.fd.io
Sent: Thursday, August 11, 2022 6:42 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Free from a vlib buffer from out a VPP worker thread

 

Hi,

 

Does anybody anticipate any issues calling  vlib_buffer_free_one to free a
buffer when running on a thread that is not registered as a VPP worker
thread.

 

Initial testing indicates that it works.

 

Regards

 

Simon

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21794): https://lists.fd.io/g/vpp-dev/message/21794
Mute This Topic: https://lists.fd.io/mt/92955560/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP 2106 Main thread is 99% CPU

[Dave Barach]

Attach to the process in gdb, switch to the main thread (if necessary), and 
type “backtrace” or “bt”. You may need to type “continue” a few times to build 
a picture of what’s going on.

 

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Saturday, May 21, 2022 2:50 AM
To: vpp-dev 
Subject: [vpp-dev] VPP 2106 Main thread is 99% CPU

 

Hello Everyone,

 

We are running VPP2106 with our plugin, we are observing a problem on load 
setup where CPU of main thread is reaching at 99% suddenly and stays there even 
if we stop load, although we dont have problems like any of your own nodes 
polling on main thread etc and even CLI is not blocking,

Could you please provide any direction to debug where the main thread is 
getting stuck ?

 

Thanks,

Chetan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21424): https://lists.fd.io/g/vpp-dev/message/21424
Mute This Topic: https://lists.fd.io/mt/91247657/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] Change how "unix exec" executes cli scripts

[Dave Barach]

The define command consumes the rest of the input line, on purpose. 

 

Try this:

 

define IP1 192.168.1.1 show macro

show macro

 

From: vpp-dev@lists.fd.io  On Behalf Of 
jiangxiaom...@outlook.com
Sent: Wednesday, May 11, 2022 10:34 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Change how "unix exec" executes cli scripts

 

Hi Damjan,
Currently command: define   also has some problem. In cli 
file have the following content:

cat /tmp/a.cli:
```
define IP1 192.168.200.11 show macro ping $IP1
```
in vpp cli will fail with the output:
```
IP1 192.168.200.11 ping: expecting IP4/IP6 address `$IP1'. Usage: ping 
{ | ipv4  | ipv6 } [ipv4  | ipv6 
] [source ] [size ] [interval ] [repeat 
] [table-id ] [burst ] [verbose] ```

The macro defined in cli file, not worked in the same cli file. 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21401): https://lists.fd.io/g/vpp-dev/message/21401
Mute This Topic: https://lists.fd.io/mt/90974441/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 g2 standalone and vpp plugin Debian packages updated

[Dave Barach]

Tested the vpp plugin w/ master/latest as of a few minutes ago. See
https://github.com/dbarach/vpp-event-viewer

 

HTH... Dave

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21272): https://lists.fd.io/g/vpp-dev/message/21272
Mute This Topic: https://lists.fd.io/mt/90547820/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 Bihash (VPP 2106)

[Dave Barach]

Not enough buckets for the number of active key/value pairs. Buckets are cheap. 
Start with nBuckets = nActiveSessions / (BIHASH_KVP_PER_PAGE / 2) or some such 
and increase the number of buckets as necessary...

 

HTH... Dave 

 

From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Thursday, April 7, 2022 7:28 AM
To: vpp-dev 
Subject: [vpp-dev] Query Regarding Bihash (VPP 2106)

 

Hi,

 

We are using bihash where key is 5 tuple of the packet.  There are different 
type of free list which are maintained and once an entry is allocated and 
removed from a bihash that memory still remain with the bihash for future 
usage. 

 

The problem we are seeing is consistent growth in the memory of bihash even 
after 24 hours of traffic , somehow memory is not coming in a stable situation.

 

Any suggestions here are really appreciated.

 

 

With 5 tuple and less buckets

Hash table 'abc_v4_flow_hash'

5260666 active elements 131072 active buckets

11 free lists

   [len 2] 50214 free elts

   [len 4] 58542 free elts

   [len 8] 69288 free elts

   [len 16] 74395 free elts

   [len 32] 77187 free elts

   [len 64] 53558 free elts

   [len 128] 1 free elts

1788 linear search buckets

heap: 25363 chunk(s) allocated

  bytes: used 2.33g, scrap 48.84m


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21223): https://lists.fd.io/g/vpp-dev/message/21223
Mute This Topic: https://lists.fd.io/mt/90310568/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] linux-cp + nat44 possible?

[Dave Barach]

https://s3-docs.fd.io/vpp/22.02/usecases/home_gateway.html - I've used vpp as a 
home gateway for years. 

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of René Weiss
Sent: Monday, January 17, 2022 12:47 PM
To: vpp-dev 
Subject: [vpp-dev] linux-cp + nat44 possible?

Hi

Is it possible to use linux-cp and nat44 together?

I'm currently playing with VPP to see if I would be able to use it on my Linux 
home gateway (mostly as an iptables/nftables replacement).

And because there I have an external and (at least) one internal interface I 
tried (unsuccessfully) to replicate that with VPP.

I was able to create a basic NAT setup based on "VPP_Home_Gateway" from the 
wiki where you get a single "lstack" interface in Linux.

Likewise, I also was able to pass VPP interfaces to Linux with "lcp create 
 host-if ".

But as soon as I try to combine the two (setup nat44 while using the forwarded 
interfaces) the external interface stops working for the Linux on the machine.

Is this something that simply will not work with VPP, or have I just not found 
the right settings yet?

Thanks,
René


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20739): https://lists.fd.io/g/vpp-dev/message/20739
Mute This Topic: https://lists.fd.io/mt/88490068/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] "make pkg-deb-debug" strips plugin / library symbols

[Dave Barach]

I decided to do a bit of leak-finding by building debug Debian packages and
installing the results.

 

The leakfinder output is approximately useless. Here's why, courtesy of
gdbserver: 

 

Reading symbols from
target:/usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so...

Reading
/usr/lib/x86_64-linux-gnu/vpp_plugins/8b510bf9c83491fed12922b444b44503a5806c
.debug from remote target...

Reading
/usr/lib/x86_64-linux-gnu/vpp_plugins/.debug/8b510bf9c83491fed12922b444b4450
3a5806c.debug from remote target...

Reading
/usr/local/lib/debug//usr/lib/x86_64-linux-gnu/vpp_plugins/8b510bf9c83491fed
12922b444b44503a5806c.debug from remote target...

Reading
/usr/local/lib/debug/usr/lib/x86_64-linux-gnu/vpp_plugins//8b510bf9c83491fed
12922b444b44503a5806c.debug from remote target...

Reading
target:/usr/local/lib/debug/usr/lib/x86_64-linux-gnu/vpp_plugins//8b510bf9c8
3491fed12922b444b44503a5806c.debug from remote target...

(No debugging symbols found in
target:/usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so)

 

This crude hack is sufficient to restore order:

 

diff --git a/src/pkg/debian/rules.in b/src/pkg/debian/rules.in

index 1958497f5..43c6efd9a 100644

--- a/src/pkg/debian/rules.in

+++ b/src/pkg/debian/rules.in

@@ -21,7 +21,7 @@ build3vers := $(shell py3versions -sv)

 dh $@ --with $(DH_WITH) --buildsystem=pybuild

 override_dh_strip:

- dh_strip --dbg-package=vpp-dbg

+ echo dont dh_strip --dbg-package=vpp-dbg

 override_dh_install:

 @for c in @VPP_COMPONENTS@; do \

 

It seems like we might want to skip the "dh_strip" step for debug Debians.
Is there a good way to do that?

 

FWIW... Dave


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20724): https://lists.fd.io/g/vpp-dev/message/20724
Mute This Topic: https://lists.fd.io/mt/88445441/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] feature arc node is NOT hitting

[Dave Barach]

A few minutes in gdb working with a debug image should make it obvious what’s 
going on. Start at the input node which implements the “device-input” arc and 
look at the data structures. E.g. dpdk_device_input(), or whatever.

 

FWIW... D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Monday, December 13, 2021 10:33 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] feature arc node is NOT hitting

 

Hi VPP experts,

We are facing some strange issue in the feature arc framwork.

We have two nodes inserted in "device-input" feature arc, for example, 
"feature1" and "feature2".

We have enabled these features on two interfaces available.

"show interface ifc-1 features"
and
"show interface ifc-2 features"

"device-input"
feature1
feature2

Above command o/p showing that both features are enabled in the device-input 
feature arc for both interfaces.

However, in the packet processing, we are observing that for one interface, 
only feature2 node is getting hit, but the packets are NOT going via feature1 
node.

Any inputs on why this could be happening (or) any hints on how to debug this 
further on this.

-- 
Thanks & Regards,
Murthy 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20632): https://lists.fd.io/g/vpp-dev/message/20632
Mute This Topic: https://lists.fd.io/mt/87699901/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 on api-trace

[Dave Barach]

See https://lists.fd.io/g/vpp-dev/message/20578


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20611): https://lists.fd.io/g/vpp-dev/message/20611
Mute This Topic: https://lists.fd.io/mt/87611500/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 on api-trace

[Dave Barach]

See 
https://lists.fd.io/g/vpp-dev/message/20578?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Capi+trace%2C20%2C2%2C0%2C87467150

 

From: vpp-dev@lists.fd.io  On Behalf Of Akash S R
Sent: Thursday, December 9, 2021 8:26 AM
To: vpp-dev ; Dave Barach ; Ole Troan 

Subject: [vpp-dev] Question on api-trace

 

Hello,

I have a query on api-trace. How to add trace to an api before configuring via 
vppctl, lets say for eg. I am creating a gtpu tunnel via vppctl, How to see the 
complete API Trace, once the command is entered. Is there any support on VPP 
for the same, If so please help on How to do that.

 

/Akash


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20610): https://lists.fd.io/g/vpp-dev/message/20610
Mute This Topic: https://lists.fd.io/mt/87611500/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 on api-trace

[Dave Barach]

See https://lists.fd.io/g/vpp-dev/message/20578

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20609): https://lists.fd.io/g/vpp-dev/message/20609
Mute This Topic: https://lists.fd.io/mt/87611500/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] View api_post_mortem files

[Dave Barach]

See the "api trace" debug CLI command. 

 

For example:

 

DBGvpp# api trace on  # start tracing, typically configured in
/etc/vpp/startup.com

DBGvpp# bin create_loopback  # create a loopback interface

DBGvpp# bin sw_interface_set_flags sw_if_index 1 admin-up   # set the
interface admin-up

DBGvpp# api trace save foo # save the binary api trace in /tmp/foo

DBGvpp# api trace dump  /tmp/foo  # dump the trace, results below...

 

HTH... Dave

 

 

vl_api_sw_interface_dump_t:

  sw_if_index: 0

  name_filter_valid: 0

  name_filter:

vl_api_control_ping_t:

vl_api_sw_interface_details_t:

  sw_if_index: 0

  sup_sw_if_index: 0

  l2_address: ..

  flags: 

  type: IF_API_TYPE_HARDWARE

  link_duplex: LINK_DUPLEX_API_UNKNOWN

  link_speed: 0

  link_mtu: 0

  mtu: 0

  mtu: 0

  mtu: 0

  mtu: 0

  sub_id: 0

  sub_number_of_tags: 0

  sub_outer_vlan_id: 0

  sub_inner_vlan_id: 0

 sub_if_flags: 

  vtr_op: 0

  vtr_push_dot1q: 0

  vtr_tag1: 0

  vtr_tag2: 0

  outer_tag: 0

  b_dmac: ..

  b_smac: ..

  b_vlanid: 0

  i_sid: 0

  interface_name: local0

  interface_dev_type: local

  tag: 

vl_api_control_ping_reply_t:

  retval: 0

  vpe_pid: 37668

vl_api_create_loopback_t:

  mac_address: ..

vl_api_create_loopback_reply_t:

  retval: 0

  sw_if_index: 1

vl_api_sw_interface_set_flags_t:

  sw_if_index: 1

  flags: IF_STATUS_API_FLAG_ADMIN_UP

vl_api_sw_interface_set_flags_reply_t:

  retval: 0

 

From: Sonia Rovner mailto:sonia.rov...@oracle.com>
> 
Sent: Thursday, December 2, 2021 5:42 PM
To: vpp-dev@lists.fd.io  
Cc: d...@barachs.net  
Subject: View api_post_mortem files

 

Hello,

 

How do I view the api_post_mortem files? 

 

Regards,

Sonia


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20578): https://lists.fd.io/g/vpp-dev/message/20578
Mute This Topic: https://lists.fd.io/mt/87467150/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] [ip punt redirect] redirect ssh traffic on vpp interface to linux host

[Dave Barach]

One scheme which works well places a Linux tap interface into a NAT "inside
network" bridge group. 

 

See https://s3-docs.fd.io/vpp/22.02/usecases/home_gateway.html

 

This may not be appropriate for your use-case, but it will work perfectly if
you can use it.

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of
haiyan...@ilinkall.cn
Sent: Monday, November 29, 2021 1:46 AM
To: vpp-dev 
Subject: [vpp-dev] [ip punt redirect] redirect ssh traffic on vpp interface
to linux host

 

Dear vpp experts,





To perform the subject described, I did as this document said
https://lists.fd.io/g/vpp-dev/message/17806, but could not redirect ssh
traffic to linux host, could someone kindly show me the detail
configuration?





if I configure linux tap0 interface the same ip/mac address with vpp nic,
how to configure vpp tap0 interface? 

 

Thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20553): https://lists.fd.io/g/vpp-dev/message/20553
Mute This Topic: https://lists.fd.io/mt/87372925/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] Bihash is considered thread-safe but probably shouldn't

[Dave Barach]

Dear Nick,

 

As the code comment suggests, we tiptoe right up to the line to extract 
performance. Have you tried e.g. ISOLCPUS, thread priority, or some other 
expedients to make the required assumptions true?

 

It’s easy enough to change the code in various ways so this use-case cannot 
backfire. High on the list: always make a working copy of the bucket, vs. 
update in place. Won’t help write performance, but it’s likely to make the pain 
go away.

 

Bucket-level reader-locks would involve adding Avogadro’s number of atomic ops 
to the predominant case. I’m pretty sure that’s a non-starter.

 

FWIW... Dave

 

 

From: vpp-dev@lists.fd.io  On Behalf Of Nick Zavaritsky
Sent: Monday, November 1, 2021 12:12 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Bihash is considered thread-safe but probably shouldn't

 

Hello bihash experts!

There's an old thread claiming that bihash lookup can produce a value=-1 under 
intense add/delete concurrent activity: 
https://lists.fd.io/g/vpp-dev/message/15606

We had a seemingly related crash recently when a lookup in snat_main.flow_hash 
yielded a value=-1 which was subsequently used as a destination thread index to 
offload to. This crash prompted me to study bihash more closely.

The rest of the message is structured as follows:
  1. Presenting reasons why I believe that bihash is not thread-safe.
  2. Proposing a fix.

1 Bihash is probably not thread-safe

The number of buckets in a hash table never changes. Every bucket has a lock 
bit. Updates happen via clib_bihash_add_del_inline_with_hash. The function 
grabs the bucket lock early on and performs update while holding the lock. 
Obviously this is safe, let's focus on readers.

Lookups happen via clib_bihash_search_inline_with_hash / 
clib_bihash_search_inline_2_with_hash. The function locates the bucket and 
waits until the lock bit is cleared.

  b = BV (clib_bihash_get_bucket) (h, hash);

 

  if (PREDICT_FALSE (BV (clib_bihash_bucket_is_empty) (b)))

return -1;

 

  if (PREDICT_FALSE (b->lock))

{

  volatile BVT (clib_bihash_bucket) * bv = b;

  while (bv->lock)

CLIB_PAUSE ();

}


>From this point on the function examines the data structure without ever 
>bothering to check the lock again. Nothing prevents an updater from changing 
>the data the reader is currently looking at, or even deallocating it right 
>away. The only way it could work is if we could make assumptions about 
>relative performance of lookup and update operations. Checking the lock early 
>in lookup ensures that there's no update currently in progress. If lookup is 
>faster than update, then no future updater will manage to progress to the 
>point where the memory is written BEFORE the lookup was complete. Indeed, we 
>have the following comment in clib_bihash_add_del_inline_with_hash:

  /*

   * Because reader threads are looking at live data,

   * we have to be extra careful. Readers do NOT hold the

   * bucket lock. We need to be SLOWER than a search, past the

   * point where readers CHECK the bucket lock.

   */

Unfortunately, the assumption doesn't hold. Any thread could get preempted at 
arbitrary time. Even if we rule out preemption, there are microarchitectural 
quirks (e.g. caches, branch misprediction) that could slow down lookup to the 
point that memory read and update will overlap. 


The core of lookup is the following loop. Please note that checking a key and 
fetching the value is not atomic, hence if we are preempted in-between the 
result could be bogus.

  for (i = 0; i < limit; i++)

{

  if (BV (clib_bihash_key_compare) (v->kvp[i].key, key_result->key))

{

  *key_result = v->kvp[i];

  return 0;

}

}


Different ways the key-value pair could get updated:

(1) Add using a previously empty slot:

  clib_memcpy_fast (&(v->kvp[i].value),

_v->value, sizeof (add_v->value));

  CLIB_MEMORY_STORE_BARRIER (); /* Make sure the value has 
settled */

  clib_memcpy_fast (&(v->kvp[i]), _v->key,

sizeof (add_v->key));


The key update is not atomic, reader could observe a key updated half-way.


(2) Add that recycles a stale slot:

  clib_memcpy_fast (&(v->kvp[i]), add_v, sizeof (*add_v));


Yet again not atomic. A reader could witness (old_k, new_v) or (new_k, old_v) 
or even an arbitrary interleaving of chunks from old and new keys.

(3) Deleting an entry:

clib_memset_u8 (&(v->kvp[i]), 0xff, sizeof (*(add_v)));

Not atomic.


2 A fix

It's worth noting that bihash never crashes. It does yield bogus results 
occasionally, though. While -1 is easy to check for, the analysis shows that 
other bogus results are possible. In particular:

  1. Value updated half-way, possible with bihash_8_16.
  2. Observing a key that never existed due to a key partial update. The 
probability is low since the hash should 

Re: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 21.06 version

[Dave Barach]

+1...

 

From: vpp-dev@lists.fd.io  On Behalf Of Mohammed Hawari
Sent: Wednesday, September 29, 2021 8:46 AM
To: Dave Barach 
Cc: Satya Murthy ; vpp-dev 
Subject: Re: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 
21.06 version

 

Hi,

 

Please note that starting with v21.01, plugin symbols are hidden by default and 
can’t be used from another plugin (or any other linked object). You need to add 
the __clib_export attribute to the symbols you want to expose to other plugins. 
For example, in the dns plugin, the dns_resolve_name function is marked with 
__clib_export, in file plugins/dns/dns.c:

 

__clib_export int
dns_resolve_name (u8 *name, dns_cache_entry_t **ep, dns_pending_request_t *t0,
  dns_resolve_name_t *rn)
{

This enables its use by the ikev2 plugin. In file plugins/ikev2/ikev2.c you 
have 

 

km->dns_resolve_name =
vlib_get_plugin_symbol ("dns_plugin.so", "dns_resolve_name”);

 

Best regards,

 

Mohammed

 

On 29 Sep 2021, at 12:59, Dave Barach mailto:v...@barachs.net> > wrote:

 

It’s worth checking that the symbol in question is actually exported. As part 
of upgrading, you may have started using a different toolchain.

 

$ nm -go .o | grep 

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Satya Murthy
Sent: Wednesday, September 29, 2021 6:43 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 
21.06 version

 

Hi,

We are trying to upgrade to fdio.2106 version from a previous version. 

After upgrading to 21.06 version with our custom plugins, we are seeing that 
vlib_get_plugin_symbol()  to resolve a symbol from another plugin is always 
returning null.
This was working fine in the earlier version.

I cross checked that load_one_plugin() is successful in loading all the 
plugins, before we call the vlib_get_plugin_symbol().

Any pointers on what could be happening here ?

-- 
Thanks & Regards,
Murthy 






 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20224): https://lists.fd.io/g/vpp-dev/message/20224
Mute This Topic: https://lists.fd.io/mt/85945383/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_get_plugin_symbol returning null after upgrading to 21.06 version

[Dave Barach]

It’s worth checking that the symbol in question is actually exported. As part 
of upgrading, you may have started using a different toolchain.

 

$ nm -go .o | grep 

 

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Wednesday, September 29, 2021 6:43 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 
21.06 version

 

Hi,

We are trying to upgrade to fdio.2106 version from a previous version. 

After upgrading to 21.06 version with our custom plugins, we are seeing that 
vlib_get_plugin_symbol()  to resolve a symbol from another plugin is always 
returning null.
This was working fine in the earlier version.

I cross checked that load_one_plugin() is successful in loading all the 
plugins, before we call the vlib_get_plugin_symbol().

Any pointers on what could be happening here ?

-- 
Thanks & Regards,
Murthy 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20221): https://lists.fd.io/g/vpp-dev/message/20221
Mute This Topic: https://lists.fd.io/mt/85945383/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 #vnet os_panic for failed barrier timeout

[Dave Barach]

This is the key bit from thread 1:

 

#3  0x7f000c0ab051 in unix_signal_handler (signum=6, si=, 
uc=) at /usr/src/debug/vpp-21.01/src/vlib/unix/main.c:187

#4  0x7f000a8995f0 in __funlockfile (stream=0x10af) at 
../nptl/sysdeps/pthread/funlockfile.c:28

 

The thread barrier timeout is a side-effect. Please try to work out what’s 
causing “_funlockfile(...)” to generate SIGABRT...

 

D. 

 

 

From: vpp-dev@lists.fd.io  On Behalf Of 
satishse...@gmail.com
Sent: Monday, September 27, 2021 8:47 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp #vnet os_panic for failed barrier timeout

 

Hi Dave,

We are seeing same issue in vpp 21.01

warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.

Core was generated by `/usr/bin/vpp -c /opt/ani/etc//startup_nrdufr2.conf'.

Program terminated with signal 6, Aborted.

#0  0x7f0009916337 in __bsd_signal (sig=4271, handler=0x10af) at 
../sysdeps/posix/signal.c:50

50 }

Missing separate debuginfos, use: debuginfo-install 
keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-46.el7.x86_64 
libcom_err-1.42.9-17.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 
libselinux-2.5-15.el7.x86_64 libuuid-2.23.2-65.el7_9.1.x86_64 
numactl-libs-2.0.12-5.el7.x86_64 pcre-8.32-17.el7.x86_64 
zlib-1.2.7-18.el7.x86_64

(gdb) thread apply bt full

(gdb) thread apply all bt

 

Thread 3 (LWP 4622):

#0  0x7f00099dee63 in capset () at ../sysdeps/unix/syscall-template.S:83

#1  0x in ?? ()

 

Thread 2 (LWP 4623):

#0  vlib_worker_thread_barrier_check () at 
/usr/src/debug/vpp-21.01/src/vlib/threads.h:440

#1  vlib_main_or_worker_loop (is_main=0, vm=0x7effcc15db00) at 
/usr/src/debug/vpp-21.01/src/vlib/main.c:1812

#2  vlib_worker_loop (vm=0x7effcc15db00) at 
/usr/src/debug/vpp-21.01/src/vlib/main.c:2038

#3  0x7f000bf9eda0 in clib_calljmp () from /usr/lib64/libvppinfra.so.21.01

#4  0x7effc1174c00 in ?? ()

#5  0x7effc53b947d in eal_thread_loop.cold () from 
/usr/lib/vpp_plugins/dpdk_plugin.so

#6  0x in ?? ()

 

Thread 1 (LWP 4271):

#0  0x7f0009916337 in __bsd_signal (sig=4271, handler=0x10af) at 
../sysdeps/posix/signal.c:50

#1  0x7f0009917a28 in __GI_abort () at abort.c:79

#2  0x55f56215a5ca in os_exit () at 
/usr/src/debug/vpp-21.01/src/vpp/vnet/main.c:433

#3  0x7f000c0ab051 in unix_signal_handler (signum=6, si=, 
uc=) at /usr/src/debug/vpp-21.01/src/vlib/unix/main.c:187

#4  0x7f000a8995f0 in __funlockfile (stream=0x10af) at 
../nptl/sysdeps/pthread/funlockfile.c:28

#5  0x0001 in ?? ()

#6  0x in ?? ()

(gdb) 

-- 
Regards,
Satish Singh 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20209): https://lists.fd.io/g/vpp-dev/message/20209
Mute This Topic: https://lists.fd.io/mt/83739741/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Rejecting large frequency change

[Dave Barach]

First, why are we adjusting the clock rate? 

 

The CPU clock read via RDTSC (x86_64) derives from a fairly cheap oscillator 
which drifts (changes frequency) over time. Integrated over a respectable 
period of time, the resulting frequency errors lead to errors in policy 
enforcement. “6am to midnight” eventually means 6:15 am to 12:15 am if a 
putative clock rate of 4gGz is actually 3.995 gHz and we don’t correct the 
clock rate.

 

See also “show clock verbose”

 

The algorithm in time.c uses the system’s idea of “now” to derive the current 
CPU frequency, uses exponential smoothing to slew vpp’s idea of the CPU 
frequency.

 

If a particular candidate rate sample jumps by too much, we ignore it and print 
a message. It wouldn’t be completely unreasonable to suppress the messages 
since they end up in syslog.

 

FWIW... Dave

 

From: Prasanth G  
Sent: Friday, September 17, 2021 2:02 AM
To: Dave Barach 
Cc: lgudi...@ciena.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Rejecting large frequency change

 

Hi Dave,

 

I am seeing this with VPP 21.01. Yes NTP is on and the print starts filling up 
the log. I see fixes made in this area in time.h and time.c addressing the 
algorithm. 

Questions:

1. "Vpp has to continuously adjust its idea of the current clock rate" -- How 
long could this be? Seconds, minutes or hours?

2. Is the warning suggesting a problem (with few expected failures around this 
event that rely on timers) or information displayed to the user that the clock 
rate is being adjusted? What is the outcome expected with entities of the 
system relying on timers whenever this happens?

 

Thanks,

Prashant

 

On Fri, Aug 6, 2021 at 5:08 AM Dave Barach mailto:v...@barachs.net> > wrote:

Which version of vpp are you running? Which Linux kernel is involved? What kind 
of hardware? Lastly, did you just start running NTP on the system?

 

Yes, of course it means something: every N seconds, vpp calculates its idea of 
the current clock frequency by asking the kernel [via the clock_gettime ( 
CLOCK_REALTIME) syscall] what time it is. It asks the CPU for the current clock 
tick [on x86_64, via “RDTSC”]. Some arithmetic later, we have a new clock rate 
for the processor. 

 

We can’t simply believe the new clock rate, because e.g. NTP synchronization 
can change the kernel reference clock by minutes or hours. Every timer in the 
system breaks catastrophically if vpp’s idea of the CPU clock rate is seriously 
wrong. After a suitable number of experiments, we decided to reject frequency 
changes of more than one percent. 

 

Vpp has to continuously adjust its idea of the current clock rate, otherwise 
long-running timers won’t be accurate enough. 

  

 

See .../src/vppinfra/time.c:clib_time_verify_frequency() and 
.../src/vppinfra/time.h:clib_time_now_internal() for details.  

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Gudimetla, Leela Sankar via 
lists.fd.io <http://lists.fd.io> 
Sent: Thursday, August 5, 2021 11:31 PM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: [vpp-dev] Rejecting large frequency change

 

Hello,

 

We have started seeing the below warning message coming continuously. Traffic 
is running on several vhost-ports and physical ports. These messages are coming 
even after a restart with a slow rate. 

VPP clib_warning: clib_time_verify_frequency:248: Rejecting large frequency 
change of 1.01%

 

Does this mean something ? 

 

Thanks,

Leela sankar





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20157): https://lists.fd.io/g/vpp-dev/message/20157
Mute This Topic: https://lists.fd.io/mt/84701132/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 2106 How to enable Pcap trace of 2 interfaces out of 4

[Dave Barach]

Short answer: not as the code stands today. 

 

It would be simple to augment pcap_sw_if_index with a bitmap to solve “n choose 
k” problems.

 

Making the scheme multi-instance would involve a significant rework, and 
effectively discards packet processing order information. I wouldn’t be in 
favor of that one.

 

FWIW... Dave  

 

From: vpp-dev@lists.fd.io  On Behalf Of sunil kumar
Sent: Monday, September 6, 2021 4:55 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP 2106 How to enable Pcap trace of 2 interfaces out of 4

 

Hi ,

 

We have to enable pcap trace for two interfaces out of four VPP interfaces  and 
in separate pcap files, Is it possible with pcap trace CLI to run it parallel 
with multiple instances?  

 

Regards,

Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20081): https://lists.fd.io/g/vpp-dev/message/20081
Mute This Topic: https://lists.fd.io/mt/85408141/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 2101 (pcap trace)

[Dave Barach]

The following configuration works as expected:

 

set term pag off

loop create

loop create

set int ip address loop0 10.20.36.1/24

set int ip address loop1 10.20.37.1/24

set int state loop0 up

set int state loop1 up

 

packet-generator new {

name s0

limit 10

size 128-128

interface loop0

node ethernet-input

data { IP4: feed.face.000 -> dead.0.0

   UDP: 10.20.36.168 -> 10.20.37.10

   UDP: 1234 -> 2345

   incrementing 114

}

}

packet-generator new {

name s1

limit 10

size 128-128

interface loop1

node ethernet-input

data { IP4: feed.face.001 -> dead.0.1

   UDP: 10.20.37.10 -> 10.20.36.168

   UDP: 1234 -> 2345

   incrementing 114

}

}

 

ip route add 10.20.36.168/32 via drop

ip route add 10.20.37.10/23 via drop

 

 

classify filter pcap mask l3 ip4 src match l3 ip4 src 10.20.37.10

classify filter pcap mask l3 ip4 dst match l3 ip4 dst 10.20.37.10

 

DBGvpp# sh class filter

Filter Used By Table(s)

-- 

packet tracer: first table none

pcap rx/tx/drop:   first table 1

 

DBGvpp# sh cla t index 1 verbose # Note the NextTbl field...

  TableIdx  Sessions   NextTbl  NextNode

 1 1 0-1

  Heap: base 0x7fffaef45000, size 128k, locked, unmap-on-destroy, name 
'classify'

  page stats: page-size 4K, total 32, mapped 2, not-mapped 30

numa 0: 2 pages, 8k bytes

  total: 127.95K, used: 1.38K, free: 126.58K, trimmable: 126.50K

  nbuckets 8, skip 1 match 2 flag 0 offset 0

  mask 

  linear-search buckets 0

 

[4]: heap offset 1280, elts 2, normal

0: [1280]: next_index 0 advance 0 opaque 0 action 0 metadata 0

k: 0a14250a

hits 10, last_heard 0.00

 

1 active elements

1 free lists

0 linear-search buckets

 

DBGvpp# sh cla t index 0 verbose

  TableIdx  Sessions   NextTbl  NextNode

 0 1-1-1

  Heap: base 0x7fffaef66000, size 128k, locked, unmap-on-destroy, name 
'classify'

  page stats: page-size 4K, total 32, mapped 2, not-mapped 30

numa 0: 2 pages, 8k bytes

  total: 127.95K, used: 1.34K, free: 126.61K, trimmable: 126.53K

  nbuckets 8, skip 1 match 1 flag 0 offset 0

  mask 

  linear-search buckets 0

 

[7]: heap offset 1280, elts 2, normal

0: [1280]: next_index 0 advance 0 opaque 0 action 0 metadata 0

k: 0a14250a

hits 10, last_heard 0.00

 

1 active elements

1 free lists

0 linear-search buckets

 

Classification which matches either an ip4 src or and ip4 dst requires two 
(chained) tables, as shown in the example above. 

 

Looking at the output you sent, classifier table 1’s NextTbl field is set to ~0 
which explains why the classification isn’t working. You don’t need to send 
traffic; make sure that you have a two-table chain with the required 
mask/matches installed.

 

If you can come up with a reproducible debug CLI sequence which results in 
incorrect table programming, please send it so we can fix it.

 

Thanks... Dave 

 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne 
(bganne) via lists.fd.io
Sent: Tuesday, August 31, 2021 12:36 PM
To: chetan bhasin ; vpp-dev 
Subject: Re: [vpp-dev] VPp 2101 (pcap trace)

 

> Any idea why it's not working? Or what I am doing wrong?

 

I am not sure, it should be working but there might be a bug lurking 
somewhere...

I'll look at it when I have time.

 

Best

ben

 

> On Thu, Aug 26, 2021, 20:59 chetan bhasin  <  mailto:chetan.bhasin...@gmail.com> > 
> wrote:

> 

> 

> Hi Benoit,

> 

> I have tried those options but it is not working , it is only 

> capturing the section classify filter rule that is based on dst ip 

> address.

> 

> 1) Tried with classify filter [Only dest ip with 10.20.36.168 is 

> coming in pcap]

> 

> classify filter pcap mask l3 ip4 src match l3 ip4 src 10.20.36.168

> 

> classify filter pcap mask l3 ip4 dst match l3 ip4 dst 10.20.36.168

> 

> pcap trace rx tx max 100 filter file capture.pcap

> 

> 

> 

> 

> vpp# show classify filter

> 

> Filter Used By Table(s)

> 

> -- 

> 

> packet tracer: first table none

> 

> pcap rx/tx/drop:   first table 1

> 

> 

> 

> 

> vpp# show classify tables index 1 verbose

> 

>   TableIdx  Sessions   NextTbl  NextNode

> 

>  1 1-1-1

> 

>   Heap: base 0x7f5db406c000, size 128k, locked, unmap-on-destroy, 

> name 'classify'

> 

>   page stats: page-size 4K, 

Re: [vpp-dev] VPP plugins in C++

[Dave Barach]

It’s possible, modulo a bunch of easily anticipated header-file and build 
system issues.

FWIW… Dave

> On Aug 31, 2021, at 9:23 AM, Satya Murthy  wrote:
> 
> Hi ,
> 
> Is it possible to develop a vpp plugin in C++ (or) does VPP framework pose 
> any restrictions ? 
> 
> Appreciate your inputs on this.
> 
> -- 
> Thanks & Regards,
> Murthy 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20052): https://lists.fd.io/g/vpp-dev/message/20052
Mute This Topic: https://lists.fd.io/mt/85275658/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-plugin-devtools

[Dave Barach]

Makes sense to me... + oddbuf, perhaps?

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Friday, August 27, 2021 9:08 AM
To: vpp-dev 
Subject: [vpp-dev] vpp-plugin-devtools


Hello,

We have more and more plugins which are intended to be developer tools, and not 
really useful in production installs.

Good examples are: unittest, bufmon, perfmon, dispatch-trace, tracedump.

I think we should move them to separate .deb package called vpp-plugin-devtools.

Thoughts?

— 
Damjan





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20039): https://lists.fd.io/g/vpp-dev/message/20039
Mute This Topic: https://lists.fd.io/mt/85185194/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 2101 , we have to reduce the frame size to 128 for our use case

[Dave Barach]

Changing VLIB_FRAME_SIZE “should just work” but you could consider adjusting 
whichever input node(s) you’re using to limit the inbound frame size.

 

Just to ask: why do you want to reduce the frame-size? 

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
Sent: Friday, August 27, 2021 1:38 AM
To: vpp-dev 
Subject: [vpp-dev] vpp 2101 , we have to reduce the frame size to 128 for our 
use case

 

Hi,

 

We have a use case where we have to reduce the frame-size to 128, changing 
VLIB_FRAME_SIZE to 128 will do the trick ? or do we need to change anything 
else other than this ? Please advise.

 

Thanks,

Chetan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20037): https://lists.fd.io/g/vpp-dev/message/20037
Mute This Topic: https://lists.fd.io/mt/85179707/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] Rejecting large frequency change

[Dave Barach]

Which version of vpp are you running? Which Linux kernel is involved? What
kind of hardware? Lastly, did you just start running NTP on the system?

 

Yes, of course it means something: every N seconds, vpp calculates its idea
of the current clock frequency by asking the kernel [via the clock_gettime (
CLOCK_REALTIME) syscall] what time it is. It asks the CPU for the current
clock tick [on x86_64, via "RDTSC"]. Some arithmetic later, we have a new
clock rate for the processor. 

 

We can't simply believe the new clock rate, because e.g. NTP synchronization
can change the kernel reference clock by minutes or hours. Every timer in
the system breaks catastrophically if vpp's idea of the CPU clock rate is
seriously wrong. After a suitable number of experiments, we decided to
reject frequency changes of more than one percent. 

 

Vpp has to continuously adjust its idea of the current clock rate, otherwise
long-running timers won't be accurate enough. 

  

 

See .../src/vppinfra/time.c:clib_time_verify_frequency() and
.../src/vppinfra/time.h:clib_time_now_internal() for details.  

 

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla,
Leela Sankar via lists.fd.io
Sent: Thursday, August 5, 2021 11:31 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Rejecting large frequency change

 

Hello,

 

We have started seeing the below warning message coming continuously.
Traffic is running on several vhost-ports and physical ports. These messages
are coming even after a restart with a slow rate. 

VPP clib_warning: clib_time_verify_frequency:248: Rejecting large frequency
change of 1.01%

 

Does this mean something ? 

 

Thanks,

Leela sankar


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19925): https://lists.fd.io/g/vpp-dev/message/19925
Mute This Topic: https://lists.fd.io/mt/84701132/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] Having trouble disabling optimization

[Dave Barach]

Take a hard look at the startup config / command-line arguments passed by “make 
run”. The Python client isn’t hooking up with vpp correctly, most likely due to 
permission issues on the binary api segment. 

 

Make sure that the python client runs as root, or as a member of the “vpp” 
group, etc. Here are couple of likely config stanzas to check, depending on 
what’s in your workspace:

 

unix {

  ...

  gid vpp

  ...

}

 

api-segment {

  gid vpp

}

 

From: vpp-dev@lists.fd.io  On Behalf Of Ivaylo Handjiiski
Sent: Wednesday, July 28, 2021 9:06 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Having trouble disabling optimization

 

Hello again,

Thank you for the reply. I can't completely understand how am I supposed to 
make it work. I successfully generated -g -O0 binaries the way you explained 
using "make build" from my vagrant vm and then I tried various scenarios:

- I copied the binaries from my vagrant vm to my device and started vpp using 
"make run" command. However , when I run my custom service which uses vpp's 
python api to configure bridge domains and etc. i get the following error:

VPP API client:: b'vl_client_disconnect:300: peer unresponsive, give up\n'

- I tried replacing the /usr/bin/vpp executable with the one from 
/build-root/install-vpp_debug-native/vpp/bin as well as all vpp .so files with 
ones from /build-root/install-vpp_debug-native/vpp/lib but got the same error.

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19879): https://lists.fd.io/g/vpp-dev/message/19879
Mute This Topic: https://lists.fd.io/mt/84378138/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] Event Logs Memory

[Dave Barach]

Before anyone invests in integrating LTTNG with vpp: it’s critical to 
understand the per-logged-event cost. I may be able to make some time to look 
at that. 

 

The vppinfra event logger costs O(100 clocks) per logged event. Even at that, 
we can’t afford to record per-packet events in speed-path data plane nodes. 

 

It would be interesting to know when vpp takes a hit due to kernel or other 
application activity, but not at an exorbitant cost.

 

FWIW... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Varun Rapelly
Sent: Monday, July 26, 2021 12:08 PM
To: v...@barachs.net; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Event Logs Memory

 



Thanks Dave.

 

Was also exploring LTTNG tracing infra for VPP. 

 

Is there any benefit of using LTTNG over elog? 

 

Did not find much details about LTTNG in the VPP mail archive either. Is it 
worth trying? 

 

On Mon, Jul 26, 2021 at 4:50 PM mailto:v...@barachs.net> > 
wrote:

Simply configure “vlib { elog-post-mortem-dump }” and look for the event log in 
/tmp/elog_post_mortem.. 

 

If vpp crashes in a horrifying way, the post mortem dump may fail. 

 

HTH... Dave 

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Varun Rapelly
Sent: Monday, July 26, 2021 4:28 AM
To: vpp-dev@lists.fd.io  
Subject: [vpp-dev] Event Logs Memory

 

Hi,

  

Is it possible to retrieve the VPP event logs (elog), if VPP crashes before 
saving the events logged using the event-logger save command?

 

If the above is not possible, what are the other options to save VPP 
events/traces in a persistent memory to debug issues in cases like the above?

--

Regards,
VR









 

-- 

Regards,
Varun Rapelly










 

-- 

Regards,
Varun Rapelly








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19875): https://lists.fd.io/g/vpp-dev/message/19875
Mute This Topic: https://lists.fd.io/mt/84454418/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] Event Logs Memory

[Dave Barach]

Simply configure “vlib { elog-post-mortem-dump }” and look for the event log in 
/tmp/elog_post_mortem.. 

 

If vpp crashes in a horrifying way, the post mortem dump may fail. 

 

HTH... Dave 

 

From: vpp-dev@lists.fd.io  On Behalf Of Varun Rapelly
Sent: Monday, July 26, 2021 4:28 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Event Logs Memory

 

Hi,

  

Is it possible to retrieve the VPP event logs (elog), if VPP crashes before 
saving the events logged using the event-logger save command?

 

If the above is not possible, what are the other options to save VPP 
events/traces in a persistent memory to debug issues in cases like the above?

--

Regards,
VR








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19870): https://lists.fd.io/g/vpp-dev/message/19870
Mute This Topic: https://lists.fd.io/mt/84454418/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] Having trouble disabling optimization

[Dave Barach]

>From the root of your workspace, “make build” will generate -g -o0 binaries…

> On Jul 22, 2021, at 8:56 AM, Ivaylo Handjiiski  wrote:
> 
> 
> Hello, 
> 
> I am trying to debug the VPP code using gdb but when I am examining or 
> printing variables most of them are .
> 
> I've built vpp with -O0 flags. I am using a vagrant vm as a building 
> environment and my build process is as follows:
> 
> make TAG=vpp_debug install-dep
> make TAG=vpp_debug pkg-deb
> 
> TAG=vpp_debug does not seem to be appropriate here, so I manually replaced 
> -O2 entries with -O0 in build-data/platforms/vpp.mk
> Then I send and install the newly created .deb files to my device running vpp 
> and start to debug locally using gdb's attach command.
> 
> Running "make pkg-deb" shows this output regarding flags:
> 
> C flags : -Wno-address-of-packed-member -march=corei7 
> -mtune=corei7-avx -O0 -g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Wall 
> -Werror -fno-common
> Linker flags: -O0 -g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Wall 
> -Werror -fno-common -pie
> 
> But variable values are still .
> 
> Any help would be much appreciated! Thanks in advance.
> 
> Best Regards,
> Ivaylo
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19846): https://lists.fd.io/g/vpp-dev/message/19846
Mute This Topic: https://lists.fd.io/mt/84378138/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] : Worker Thread Deadlock Detected from vl_api_clnt_node

[Dave Barach]

None that I know of. 

 

Without more data – see 
https://fd.io/docs/vpp/master/troubleshooting/reportingissues/reportingissues.html
 - it’s hard to imagine helping to solve the problem.

 

Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Friday, July 9, 2021 12:49 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] : Worker Thread Deadlock Detected from vl_api_clnt_node

 

Hi Rajith / Dave,

We are on fdio.2005 version and see this same crash when we are doing packet 
tracing.
Is there any specific patch/commit that improves the situation of this locking.

If so, Can you please let us know the commit info.

-- 
Thanks & Regards,
Murthy 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19734): https://lists.fd.io/g/vpp-dev/message/19734
Mute This Topic: https://lists.fd.io/mt/78681829/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 use span api in c code?

[Dave Barach]

That doc URL is from 17.04. 

 

See span_add_delete_entry() in span.[ch].

 

HTH... Dave 

 

From: vpp-dev@lists.fd.io  On Behalf Of hemant via
lists.fd.io
Sent: Wednesday, July 7, 2021 5:40 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] how to use span api in c code?

 

I see

 

https://docs.fd.io/vpp/17.04/span_doc.html

 

The link about says this is the api: : sw_interface_span_enable_disable

 

I call the API in C code as: 

sw_interface_span_enable_disable ("TenGigabitEthernet3/0/0",
"TenGigabitEthernet3/0/1", 3, true);

 

When I compile the code I get this error:

 

error: implicit declaration of function 'sw_interface_span_enable_disable'
is invalid in C99 [-Werror,-Wimplicit-function-declaration]

 

What header file do I need to include? Span.h doesn't include this api.

 

Hemant

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19715): https://lists.fd.io/g/vpp-dev/message/19715
Mute This Topic: https://lists.fd.io/mt/84055396/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] Prefetches improvement for VPP Arm generic image

[Dave Barach]

“Going across the whole codebase and replacing prefetch macros is something we 
should definitely avoid.”

 

+1, for sure... FWIW... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Monday, July 5, 2021 4:50 AM
To: Lijian Zhang 
Cc: vpp-dev ; nd ; Honnappa Nagarahalli 
; Govindarajan Mohandoss 
; Tianyu Li ; Nitin Saxena 

Subject: Re: [vpp-dev] Prefetches improvement for VPP Arm generic image

 

Hi Lijian,

 

It will be good to know if 128 byte cacheline is something ARM platforms will 
be using in the future or it is just historical.

 

Cacheline size problem is not just about prefetching, even bigger issue is 
false sharing, so we need to address both.

Probably best solution is to have 2 VPP images, one for 128 and one for 64 byte 
cacheline size.

 

Going across the whole codebase and replacing prefetch macros is something we 
should definitely avoid.

 

— 

Damjan





On 05.07.2021., at 07:28, Lijian Zhang mailto:lijian.zh...@arm.com> > wrote:

 

Hi Damjan,

I committed several patches to address some issues around cache-line 
definitions in VPP.

 

Patch [1.1] is to resolve the build error [2] on 64Byte cache line Arm CPUs, 
e.g., ThunderX2, NeoverseN1, caused by the commit ( 
 https://gerrit.fd.io/r/c/vpp/+/32996, 
build: remove unused files and sections).

It also supports building Arm generic image (with command of “make 
build-release”) with 128Byte cache line definition, and building native image 
with 64Byte cache line definition on some Arm CPUs, e.g., ThunderX2, NeoverseN1 
(with command of “make build-release TARGET_PLATFORM=native”).

 

Patch [1.5] is to set the default cache line definition in Arm generic image 
from 128Byte to 64Byte.

Setting cache line definition to 128Byte for Arm generic image is required for 
ThunderX1 (with 128Byte physical cache line), which is also the build machine 
in   FD.io lab. I’m thinking for setting 64Byte cache line 
definition in VPP for Arm image, which will affect ThunderX1 and OcteonTX2 
CPUs. So it requires the confirmation by Marvell.

 

Arm architecture CPUs have 128Byte or 64Byte physical designs. So no matter the 
cache line definition is 128Byte or 64Byte in VPP source code, the prefetch 
functions in generic image will not work properly on all Arm CPUs. Patches 
[1.2] [1.3] [1.4] are to resolve the issue.

 

For example when running Arm generic image (cache-line-size is defined as 128B 
in Makefile for all Arm architectures) on 64Byte cache-line-size CPUs, e.g., 
Neoverse-N1, Ampere altra, ThunderX2.

 

[3] shows the prefetch macro definitions in VPP. Using CLIB_PREFETCH(), you can 
prefetch data resides in multiple cache lines.

[4] shows some usage examples of the prefetch macros in VPP. When running Arm 
generic image (128B cache-line-size definition) on 64B cache-line CPUs (N1SDP 
for example), 4.2, 4.3 and 4.4 have issues.

*   For 4.2, the input for size parameter is 68. On N1SDP with 64B 
cache-line-size, there should be two prefetch instructions executed, but due to 
68 is less than CLIB_CACHE_LINE_BYTES (128Byte definition in VPP), only the 
first prefetch instruction is executed.
*   For 4.3, if sizeof (ip0[0]) equals 68 or any other values larger than 
64B, there will be the same issue as 4.2.
*   For 4.4, the code  is trying to prefetch the first 128B of packet 
content. It assumes  CLIB_CACHE_LINE_BYTES is 64B always. In Arm generic image, 
the input for size parameter is 256B, which will execute prefetches on 
unexpected cache-lines (expected prefetches on 64B-0 and 64B-1, but actually on 
B64-0 and B64-2) .

Packet content: [64B-0][64B-1][64B-2][64B-3]

 

Our proposal is introduce a macro CLIB_N_CACHELINE_BYTES via VPP multi-arch 
feature (check patch [1.2]), to reflect the runtime CPU cache-line-size in Arm 
generic image, so that the prefetch instructions can be executed correctly.

Then for 4.4, we will need to modify the parameter for size, from 
2*CLIB_CACHE_LINE_BYTES to 128B, to reflect the actual intention.

 

Some additional macros [1.3] can be added for users to do prefetch based on 
number of cache-lines, besides number of bytes.

 

Could you please suggest on the issue and proposal?

 

[1]. Patches

[1.1] build: support 128B/64B cache line size in Arm image,  
 https://gerrit.fd.io/r/c/vpp/+/32968/2

[1.2] vppinfra: refactor prefetch macro,  
 https://gerrit.fd.io/r/c/vpp/+/32969/3

[1.3] vppinfra: fix functions to prefetch single line,  
 https://gerrit.fd.io/r/c/vpp/+/32970/2

[1.4] misc: correct prefetch macro usage,  
 https://gerrit.fd.io/r/c/vpp/+/32971/3

[1.5] build: set 64B cache line size in Arm image,  
 https://gerrit.fd.io/r/c/vpp/+/32972/2

 

[2]. Error message

Re: [vpp-dev] #vpp #vnet os_panic for failed barrier timeout

[Dave Barach]

Given the reported MTBF of 9 months and nearly 2-year-old software,
switching to 21.01 [and then to 21.06 when released] seems like the only
sensible next step.

 

>From the gdb info provided, it looks like there is one worker thread. Is
that correct? If so, the "workers_at_barrier" count seems correct, so why
wouldn't the main thread have moved on instead of spinning waiting for
something which already happened? 

 

D.

 

 

From: vpp-dev@lists.fd.io  On Behalf Of Bly, Mike via
lists.fd.io
Sent: Wednesday, June 23, 2021 10:59 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] #vpp #vnet os_panic for failed barrier timeout

 

We are looking for advise on whether this os_panic() for a barrier timeout
has anyone looking at it. We see in the forum many instances of type of main
thread back-trace. For this incedent, referencing the sw_interface_dump API
we created a lighter oper-get call to simply fetch link state vs. all of the
extensive information the dump command fetches for each interface. At the
time we added our new oper-get function,  we overlooked the "is_mp_safe"
enablement for dump and as such did NOT set it for our new oper-get. The end
result is a fairly light API that requires barrier support. When this issue
occurred the configuration was using a single separate worker thread so the
API is waiting for a barrier count of 1. Interestingly, the BT analysis
shows the count value was met, which implies some deeper issue. Why did a
single worker, with at most 10s of packets per second workload at the time
fail to stall at a barrier within the allotted one second timeout value?
And, even more fun to answer is why we even reached the os_panic call as the
BT shows the worker was stalled at the barrier. Please refer to GDB analysis
at bottom of this email.

 

This code is based on 19.08. We are in the process of upgrading to 21.01,
but in review of the forum posts, this type of BT is seen across many
versions. This is an extremely rare event. We had one occurrence in
September of last year that we could not reproduce and then just had a
second occurrence this week. As such, we are not able to reproduce this on
demand, let alone in stock VPP code given this is a new API.

 

While we could simply enable is_mp_safe as done for sw_interface_dump to
avoid the issue, we are troubled at not being able to explain why the
os_panic occurred in the first place. As such, we are hoping someone might
be able to provide guidance here on next steps. What additional details from
the core-file can we provide?

 

Thread 1 backtrace

#0 __GI_raise (sig=sig@entry=6) at
/usr/src/debug/glibc/2.30-r0/git/sysdeps/unix/sysv/linux/raise.c:50
#1 0x003cb8425548 in __GI_abort () at
/usr/src/debug/glibc/2.30-r0/git/stdlib/abort.c:79
#2 0x004075da in os_exit () at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vpp/vnet/main.c:37
9
#3 0x7ff1f5740794 in unix_signal_handler (signum=,
si=, uc=)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlib/unix/main.c:1
83
#4 
#5 __GI_raise (sig=sig@entry=6) at
/usr/src/debug/glibc/2.30-r0/git/sysdeps/unix/sysv/linux/raise.c:50
#6 0x003cb8425548 in __GI_abort () at
/usr/src/debug/glibc/2.30-r0/git/stdlib/abort.c:79
#7 0x00407583 in os_panic () at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vpp/vnet/main.c:35
5
#8 0x7ff1f5728643 in vlib_worker_thread_barrier_sync_int
(vm=0x7ff1f575ba40 , func_name=)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlib/threads.c:147
6
#9 0x7ff1f62c6d56 in vl_msg_api_handler_with_vm_node
(am=am@entry=0x7ff1f62d8d40 , the_msg=0x1300ba738,
vm=vm@entry=0x7ff1f575ba40 ,
node=node@entry=0x7ff1b588c000)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlibapi/api_shared
.c:583
#10 0x7ff1f62b1237 in void_mem_api_handle_msg_i (am=,
q=, node=0x7ff1b588c000,
vm=0x7ff1f575ba40 ) at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlibmemory/memory_
api.c:712
#11 vl_mem_api_handle_msg_main (vm=vm@entry=0x7ff1f575ba40
, node=node@entry=0x7ff1b588c000)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlibmemory/memory_
api.c:722
#12 0x7ff1f62be713 in vl_api_clnt_process (f=,
node=, vm=)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlibmemory/vlib_ap
i.c:326
#13 vl_api_clnt_process (vm=, node=,
f=)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlibmemory/vlib_ap
i.c:252
#14 0x7ff1f56f90b7 in vlib_process_bootstrap (_a=)
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vlib/main.c:1468
#15 0x7ff1f561f220 in clib_calljmp () at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vppinfra/longjmp.S
:123
#16 0x7ff1b5e39db0 in ?? ()
#17 0x7ff1f56fc669 in vlib_process_startup (f=0x0, p=0x7ff1b588c000,
vm=0x7ff1f575ba40 )
at
/usr/src/debug/vpp/19.08+gitAUTOINC+6641eb3e8f-r0/git/src/vppinfra/types.h:1
33

Thread 3 backtrace

(gdb) thr 3
[Switching to thread 3 (LWP 440)]
#0 

Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp #vpp-dev

[Dave Barach]

This is a different code path which might need the same sort of fix.

 

Looks likely that you sent a VL_API_DELETE_LOOPBACK message. AFAICT that 
message is not marked thread-safe, so it will be processed on thread 0 with the 
thread barrier held. 

 

D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of sontu mazumdar
Sent: Friday, June 18, 2021 5:57 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash 
#vpp #vpp-dev

 

Hi Dave,

This hash node key corruption I observed while debugging a VPP crash due to 
node_by_name hash access which seems to be corrupted.
So I thought the unix-cli-local node might be the root cause, but after the 
patch also we saw the crash again. The bt looks like below.




*  Frame 00: /lib64/libpthread.so.0(+0x14a90) [0x7ff07d7dea90]
*  Frame 01: /lib64/libvppinfra.so.20.05.1(hash_memory+0x30) 
[0x7ff07d9548a0]
*  Frame 02: /lib64/libvppinfra.so.20.05.1(+0x23ce0) [0x7ff07d954ce0]
*  Frame 03: /lib64/libvppinfra.so.20.05.1(_hash_set3+0xfd) [0x7ff07d955dfd]
*  Frame 04: /lib64/libvppinfra.so.20.05.1(+0x24c71) [0x7ff07d955c71]
*  Frame 05: /lib64/libvlib.so.20.05.1(vlib_node_rename+0xa9) 
[0x7ff07daf2b49]
*  Frame 06: /lib64/libvnet.so.20.05.1(vnet_delete_hw_interface+0x4eb) 
[0x7ff07eae3f9b]
*  Frame 07: /lib64/libvnet.so.20.05.1(ethernet_delete_interface+0x713) 
[0x7ff07eb14673]
*  Frame 08: 
/lib64/libvnet.so.20.05.1(vnet_delete_loopback_interface+0x119) [0x7ff07eb16169]
*  Frame 09: /lib64/libvnet.so.20.05.1(+0xf816b4) [0x7ff07eaf06b4]
*  Frame 10: 
/lib64/libvlibmemory.so.20.05.1(vl_msg_api_socket_handler+0x11c) 
[0x7ff07f3a101c]
*  Frame 11: 
/lib64/libvlibmemory.so.20.05.1(vl_socket_process_api_msg+0x18) [0x7ff07f38e9b8]


I have one question regarding the changes, don't we need to take thread_barrier 
lock before updating the hash node_by_name ?

Regards,
Sontu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19612): https://lists.fd.io/g/vpp-dev/message/19612
Mute This Topic: https://lists.fd.io/mt/83471274/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp #vpp-dev

[Dave Barach]

Ack, thanks... See https://gerrit.fd.io/r/c/vpp/+/32688; merged in 
master/latest. Cherry-picked into stable/2106, should cherry-pick into older 
releases if needed.

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of sontu mazumdar
Sent: Sunday, June 13, 2021 1:35 PM
To: Dave Barach 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash 
#vpp #vpp-dev

 

Thanks for the patch Dave. 

With this I am not seeing the corruption
issue of node hash key in node_by_name hash. 

 

Regards, 

Sontu

 

On Sat, 12 Jun, 2021, 11:09 AM sontu mazumdar, mailto:sont...@gmail.com> > wrote:

Thanks Dave.

I will try with your suggested code changes and will share the result. 

 

Regards,

Sontu

 

On Fri, 11 Jun, 2021, 9:34 PM Dave Barach, mailto:v...@barachs.net> > wrote:

Please try these diffs and report results.

 

diff --git a/src/vlib/unix/cli.c b/src/vlib/unix/cli.c

index 6c9886725..ce29e0723 100644

--- a/src/vlib/unix/cli.c

+++ b/src/vlib/unix/cli.c

@@ -2863,6 +2863,7 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name, int 
fd)

{

   unix_main_t *um = _main;

   clib_file_main_t *fm = _main;

+  vlib_node_main_t *nm = _get_main()->node_main;

   unix_cli_file_t *cf;

   clib_file_t template = { 0 };

   vlib_main_t *vm = um->vlib_main;

@@ -2896,10 +2897,12 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name, 
int fd)

   old_name = n->name;

   n->name = (u8 *) name;

 }

+  ASSERT(old_name);

+  hash_unset (nm->node_by_name, old_name);

+  hash_set (nm->node_by_name, name, n->index);

   vec_free (old_name);

   vlib_node_set_state (vm, n->index, VLIB_NODE_STATE_POLLING);

-

   _vec_len (cm->unused_cli_process_node_indices) = l - 1;

 }

   else

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of sontu mazumdar
Sent: Friday, June 11, 2021 11:34 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp 
#vpp-dev

 

Hi,

 

I observe that in node_by_name hash we store a node with name 
"unix-cli-local:0" and node index 720 (not sure the purpose of the node).

The node name is stored as key in the node_by_name hash.

But later at some time when I print the node_by_name hash's each entry I see 
the key of node i.e the node name is printing some junk value (I figured it out 
via checking it against the node index).

 

When I looked at code in unix_cli_file_add(), below we are first time adding 
the node with name "unix-cli-local:0".

 

  static vlib_node_registration_t r = {

.function = unix_cli_process,

.type = VLIB_NODE_TYPE_PROCESS,

.process_log2_n_stack_bytes = 18,

  };

 

  r.name <http://r.name>  = name;

 

  vlib_worker_thread_barrier_sync (vm);

 

  vlib_register_node (vm, );   <<<<<<<<<<<<

  vec_free (name);

 

  n = vlib_get_node (vm, r.index);

  vlib_worker_thread_node_runtime_update ();

  vlib_worker_thread_barrier_release (vm);

 

 

Later it again calls unix_cli_file_add(), there we pass a different name 
"unix-cli-local:1".

In this case we are overwriting the already existing node name from 
"unix-cli-local:0" to "unix-cli-local:1".

 

  for (i = 0; i < vec_len (vlib_mains); i++)

{

  this_vlib_main = vlib_mains[i];

  if (this_vlib_main == 0)

continue;

  n = vlib_get_node (this_vlib_main,

 cm->unused_cli_process_node_indices[l - 1]);

  old_name = n->name;  <<<<<<<<<<<

  n->name = (u8 *) name;   <<<<<<<<<<<

}

  vec_free (old_name);  <<<<<<<<<<

 

But the node name is already present in node_by_name hash as a key and there we 
haven't updated it instead we have deleted the old name.

This is resulting in printing some corrupted node name for the above node in 
node_by_name hash, which I think can sometimes results in VPP crash also as the 
hash key points to some freed memory.

 

Regards,

Sontu






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19564): https://lists.fd.io/g/vpp-dev/message/19564
Mute This Topic: https://lists.fd.io/mt/83471274/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp #vpp-dev

[Dave Barach]

Please try these diffs and report results.

 

diff --git a/src/vlib/unix/cli.c b/src/vlib/unix/cli.c

index 6c9886725..ce29e0723 100644

--- a/src/vlib/unix/cli.c

+++ b/src/vlib/unix/cli.c

@@ -2863,6 +2863,7 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name, int 
fd)

{

   unix_main_t *um = _main;

   clib_file_main_t *fm = _main;

+  vlib_node_main_t *nm = _get_main()->node_main;

   unix_cli_file_t *cf;

   clib_file_t template = { 0 };

   vlib_main_t *vm = um->vlib_main;

@@ -2896,10 +2897,12 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name, 
int fd)

   old_name = n->name;

   n->name = (u8 *) name;

 }

+  ASSERT(old_name);

+  hash_unset (nm->node_by_name, old_name);

+  hash_set (nm->node_by_name, name, n->index);

   vec_free (old_name);

   vlib_node_set_state (vm, n->index, VLIB_NODE_STATE_POLLING);

-

   _vec_len (cm->unused_cli_process_node_indices) = l - 1;

 }

   else

 

From: vpp-dev@lists.fd.io  On Behalf Of sontu mazumdar
Sent: Friday, June 11, 2021 11:34 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp 
#vpp-dev

 

Hi,

 

I observe that in node_by_name hash we store a node with name 
"unix-cli-local:0" and node index 720 (not sure the purpose of the node).

The node name is stored as key in the node_by_name hash.

But later at some time when I print the node_by_name hash's each entry I see 
the key of node i.e the node name is printing some junk value (I figured it out 
via checking it against the node index).

 

When I looked at code in unix_cli_file_add(), below we are first time adding 
the node with name "unix-cli-local:0".

 

  static vlib_node_registration_t r = {

.function = unix_cli_process,

.type = VLIB_NODE_TYPE_PROCESS,

.process_log2_n_stack_bytes = 18,

  };

 

  r.name = name;

 

  vlib_worker_thread_barrier_sync (vm);

 

  vlib_register_node (vm, );   

  vec_free (name);

 

  n = vlib_get_node (vm, r.index);

  vlib_worker_thread_node_runtime_update ();

  vlib_worker_thread_barrier_release (vm);

 

 

Later it again calls unix_cli_file_add(), there we pass a different name 
"unix-cli-local:1".

In this case we are overwriting the already existing node name from 
"unix-cli-local:0" to "unix-cli-local:1".

 

  for (i = 0; i < vec_len (vlib_mains); i++)

{

  this_vlib_main = vlib_mains[i];

  if (this_vlib_main == 0)

continue;

  n = vlib_get_node (this_vlib_main,

 cm->unused_cli_process_node_indices[l - 1]);

  old_name = n->name;  <<<

  n->name = (u8 *) name;   <<<

}

  vec_free (old_name);  <<

 

But the node name is already present in node_by_name hash as a key and there we 
haven't updated it instead we have deleted the old name.

This is resulting in printing some corrupted node name for the above node in 
node_by_name hash, which I think can sometimes results in VPP crash also as the 
hash key points to some freed memory.

 

Regards,

Sontu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19561): https://lists.fd.io/g/vpp-dev/message/19561
Mute This Topic: https://lists.fd.io/mt/83471274/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

[Dave Barach]

Before you go any further, decide how many PPS the overall system needs to 
process. If the answer isn’t “as many as possible,” or “several million PPS,” 
you’d be better off feeding packets to/from vpp over a memif channel or via the 
host stack from a separate process. 

 

If you decide to continue down the path of building vpp into your application: 
fabricate a plugin which creates a custom device class and interface to handle 
packet I/O to/from the application.

 

FWIW... Dave

 

From: Akash S R  
Sent: Thursday, June 10, 2021 11:06 AM
To: Dave Barach 
Cc: vpp-dev@lists.fd.io; srilcha...@gmail.com
Subject: Re: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

 

Thanks for the quick reply.
So if I need to take inputs from application and proceed to further processing, 
what is the way to do so?
Should I still be using 2 binaries?

 

Regards,

Akash

 

On Thu, Jun 10, 2021 at 6:31 PM Dave Barach mailto:v...@barachs.net> > wrote:

Vpp seems to be its dispatch loop, waiting for an input node to inject work 
into the forwarding graph. What you call cust_main() is the moral equivalent of 
a while(1) loop. It won’t return.

 

D. 

 

From: Akash S R mailto:akashsr.akas...@gmail.com> > 
Sent: Thursday, June 10, 2021 7:38 AM
To: Akash S R mailto:akashsr.akas...@gmail.com> >
Cc: v...@barachs.net <mailto:v...@barachs.net> ; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> ; srilcha...@gmail.com 
<mailto:srilcha...@gmail.com> 
Subject: Re: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

 

Hi Dave,

 

As per your suggestion, we have compiled a shared library and renamed main in 
vnet/main.c as cust_main ().

Invoking the cust_main() from our application results in a hang. Bt as below:

 

Thread 1 "vpp_main" received signal SIGINT, Interrupt.

0x7519d888 in clib_time_now_internal (c=0x7fffb3115680, 
n=287541441385032)

at /home/soundarya/june4/vpp/src/vppinfra/time.h:219

219   if (PREDICT_FALSE

Missing separate debuginfos, use: debuginfo-install check-0.9.9-5.el7.x86_64 
keyutils-libs-1.5.8-3.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 
libselinux-2.5-15.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 
libuuid-2.23.2-65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 
numactl-libs-2.0.12-5.el7.x86_64 pcre-8.32-17.el7.x86_64 
pkcs11-helper-1.11-3.el7.x86_64

(gdb) thread apply all bt

 

Thread 2 (Thread 0x7fffac0de700 (LWP 10052)):

#0  0x76ad0fd3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81

#1  0x7fffb03dae84 in eal_intr_thread_main () from 
/home/soundarya/june4/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so

#2  0x77b53ea5 in start_thread (arg=0x7fffac0de700) at 
pthread_create.c:307

#3  0x76ad09fd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 1 (Thread 0x73218940 (LWP 10048)):

#0  0x751a57f9 in vlib_main_or_worker_loop (vm=0x7fffb3115680, 
is_main=1) at /home/soundarya/june4/vpp/src/vlib/main.c:1764

#1  0x751a599e in vlib_main_loop (vm=0x7fffb3115680) at 
/home/soundarya/june4/vpp/src/vlib/main.c:1794

#2  0x751a69f6 in vlib_main (vm=0x7fffb3115680, input=0x7fffae6c3fb0) 
at /home/soundarya/june4/vpp/src/vlib/main.c:2083

#3  0x752118c1 in thread0 (arg=140736197645952) at 
/home/soundarya/june4/vpp/src/vlib/unix/main.c:671

#4  0x77e5d638 in clib_calljmp () at 
/home/5G/vpp/src/vppinfra/longjmp.S:123

#5  0x7fffafa0 in ?? ()

#6  0x75212010 in vlib_unix_main (argc=37, argv=0x46a3c0) at 
/home/soundarya/june4/vpp/src/vlib/unix/main.c:751

#7  0x77f2774e in cust_main (argc=37, argv=0x46a3c0) at 
/home/soundarya/june4/vpp/src/vpp/vnet/main.c:339

#8  0x0041757c in main () at 
/home/soundarya/june4/ViNGC/upf/DataPlane/packetProcessing/vpp/dp/sim/src/altvppsim.c:119

(gdb)

 

Any points to resolve it?

 

Thanks in Advance!

 

Regards, 

Akash

 

On Wed, May 19, 2021 at 5:48 PM Akash S R via lists.fd.io <http://lists.fd.io>  
mailto:gmail@lists.fd.io> > wrote:

Thanks Dave, Will check it out and get back here if any query is to be 
addressed. 

 

Regards,

Akash

 

On Wed, May 19, 2021, 4:51 PM mailto:v...@barachs.net> > 
wrote:

Long ago, we decided to strictly separate the vpp data plane process from its 
control plane process(es); as a matter of fault containment if nothing else.

 

As a practical matter, if you want to build vpp as a library you could change 
.../src/vpp/vnet/main.c in trivial ways, and adjust .../src/vpp/CMakeLists.txt 
to build a shared library instead of a standalone binary.

 

Bottom line: I wouldn’t go there myself for any number of reasons, but it 
wouldn’t be difficult.

 

HTH... Dave

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Akash S R
Sent: Wednesday, May 19, 2021 6:31 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd

Re: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

[Dave Barach]

Vpp seems to be its dispatch loop, waiting for an input node to inject work 
into the forwarding graph. What you call cust_main() is the moral equivalent of 
a while(1) loop. It won’t return.

 

D. 

 

From: Akash S R  
Sent: Thursday, June 10, 2021 7:38 AM
To: Akash S R 
Cc: v...@barachs.net; vpp-dev@lists.fd.io; srilcha...@gmail.com
Subject: Re: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

 

Hi Dave,

 

As per your suggestion, we have compiled a shared library and renamed main in 
vnet/main.c as cust_main ().

Invoking the cust_main() from our application results in a hang. Bt as below:

 

Thread 1 "vpp_main" received signal SIGINT, Interrupt.

0x7519d888 in clib_time_now_internal (c=0x7fffb3115680, 
n=287541441385032)

at /home/soundarya/june4/vpp/src/vppinfra/time.h:219

219   if (PREDICT_FALSE

Missing separate debuginfos, use: debuginfo-install check-0.9.9-5.el7.x86_64 
keyutils-libs-1.5.8-3.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 
libselinux-2.5-15.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 
libuuid-2.23.2-65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 
numactl-libs-2.0.12-5.el7.x86_64 pcre-8.32-17.el7.x86_64 
pkcs11-helper-1.11-3.el7.x86_64

(gdb) thread apply all bt

 

Thread 2 (Thread 0x7fffac0de700 (LWP 10052)):

#0  0x76ad0fd3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81

#1  0x7fffb03dae84 in eal_intr_thread_main () from 
/home/soundarya/june4/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so

#2  0x77b53ea5 in start_thread (arg=0x7fffac0de700) at 
pthread_create.c:307

#3  0x76ad09fd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 1 (Thread 0x73218940 (LWP 10048)):

#0  0x751a57f9 in vlib_main_or_worker_loop (vm=0x7fffb3115680, 
is_main=1) at /home/soundarya/june4/vpp/src/vlib/main.c:1764

#1  0x751a599e in vlib_main_loop (vm=0x7fffb3115680) at 
/home/soundarya/june4/vpp/src/vlib/main.c:1794

#2  0x751a69f6 in vlib_main (vm=0x7fffb3115680, input=0x7fffae6c3fb0) 
at /home/soundarya/june4/vpp/src/vlib/main.c:2083

#3  0x752118c1 in thread0 (arg=140736197645952) at 
/home/soundarya/june4/vpp/src/vlib/unix/main.c:671

#4  0x77e5d638 in clib_calljmp () at 
/home/5G/vpp/src/vppinfra/longjmp.S:123

#5  0x7fffafa0 in ?? ()

#6  0x75212010 in vlib_unix_main (argc=37, argv=0x46a3c0) at 
/home/soundarya/june4/vpp/src/vlib/unix/main.c:751

#7  0x77f2774e in cust_main (argc=37, argv=0x46a3c0) at 
/home/soundarya/june4/vpp/src/vpp/vnet/main.c:339

#8  0x0041757c in main () at 
/home/soundarya/june4/ViNGC/upf/DataPlane/packetProcessing/vpp/dp/sim/src/altvppsim.c:119

(gdb)

 

Any points to resolve it?

 

Thanks in Advance!

 

Regards, 

Akash

 

On Wed, May 19, 2021 at 5:48 PM Akash S R via lists.fd.io   
mailto:gmail@lists.fd.io> > wrote:

Thanks Dave, Will check it out and get back here if any query is to be 
addressed. 

 

Regards,

Akash

 

On Wed, May 19, 2021, 4:51 PM mailto:v...@barachs.net> > 
wrote:

Long ago, we decided to strictly separate the vpp data plane process from its 
control plane process(es); as a matter of fault containment if nothing else.

 

As a practical matter, if you want to build vpp as a library you could change 
.../src/vpp/vnet/main.c in trivial ways, and adjust .../src/vpp/CMakeLists.txt 
to build a shared library instead of a standalone binary.

 

Bottom line: I wouldn’t go there myself for any number of reasons, but it 
wouldn’t be difficult.

 

HTH... Dave

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Akash S R
Sent: Wednesday, May 19, 2021 6:31 AM
To: vpp-dev@lists.fd.io  
Cc: srilcha...@gmail.com  
Subject: [vpp-dev] Quick question on VPP on : How to Embed VPP as library

 

Hi All,

We are using VPP version 21.06 (Latest)
We understand that vpp package consists of libraries , plugins,dev and debugs 
utilities and runs as exe . 
But as per our current usage , we have a control plane application layer from 
which we have included VPP packages as libraries from our Makefile . We launch 
VPP as a separate process and we invoke VAPI's using socket.

What is the way to embed VPP directly as a library (Instead of a separate 
process ) and directly invoke VAPI's from control plane applications ?

This is important since we need to know how to deliver VPP as a library to our 
client. Please Reply Back if any Related Solution is known.

 

Thanks in Advance!

 

Regards,

Akash





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19550): https://lists.fd.io/g/vpp-dev/message/19550
Mute This Topic: https://lists.fd.io/mt/82933046/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] subinterface's ip did not deleted after subinterface deleted

[Dave Barach]

Certainly looks wrong. As a workaround, try removing the address prior to 
deleting the subinterface. 

 

I’ll have a look when I can. Please do not unicast tech support requests. 

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of 
jiangxiaom...@outlook.com
Sent: Friday, May 28, 2021 12:43 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] subinterface's ip did not deleted after subinterface deleted

 

Hi Dave Barach: 

Subinterface's ip did not deleted after subinterface deleted. Hrere is the 
test command

set interface state eth0 up

create sub-interface eth0 1

set interface ip addr eth0.1 192.168.1.1/24

show int addr

delete sub-interface eth0.1

set interface ip addr eth0 192.168.1.1/24

in cli get following error:

DBGvpp# set interface state eth0 up

DBGvpp# create sub-interface eth0 1

eth0.1

DBGvpp# set interface ip addr eth0.1 192.168.1.1/24

DBGvpp# show int addr

eth0 (up):

eth0.1 (dn):

  L3 192.168.1.1/24

local0 (dn):

DBGvpp# delete sub-interface eth0.1

DBGvpp# set interface ip addr eth0 192.168.1.1/24

set interface ip address: Prefix 192.168.1.1/24 already found on interface 
DELETED


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19496): https://lists.fd.io/g/vpp-dev/message/19496
Mute This Topic: https://lists.fd.io/mt/83142347/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] unformat_vnet_uri not implemented following RFC 3986

[Dave Barach]

IIRC it's exactly because ipv6 addresses use ':' (and "::") as chunk 
separators. If you decide to change unformat_vnet_uri please test ipv6 cases 
carefully.

D.  

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Florin Coras
Sent: Thursday, May 27, 2021 1:05 AM
To: 江 晓明 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] unformat_vnet_uri not implemented following RFC 3986

Hi, 

That unformat function and the associated session layer apis (e.g., 
vnet_connect_uri) are mainly used for testing and their production use is 
discouraged. Provided that functionality is not lost, if anybody wants to do 
the work, I don’t see why we wouldn’t want to make the unformat function rfc 
compliant. At this point I can’t remember why we settled on the use of “/“ but 
I suspect it may have to do with easier parsing of ipv6 ips. 

Regards,
Florin

> On May 26, 2021, at 8:04 PM, jiangxiaom...@outlook.com wrote:
> 
> Hi Florin:
> Currently unformat_vnet_uri not implemented following RFC 3986. The 
> syntax `tcp://10.0.0.1/500` should be `tcp://10.0.0.1:500` in rfc 3986.
> I noticed in there is a comment for `unformat_vent_uri` in 
> `src/vnet/session/application_interface.c`,
> ```
> /**
>  * unformat a vnet URI
>  *
>  * transport-proto://[hostname]ip46-addr:port
>  * eg.  tcp://ip46-addr:port
>  *  tls://[testtsl.fd.io]ip46-addr:port
>  *
>  ...
> ```
> Does it mean `unformat_vnet_uri` will be refactored following rfc in future?
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19488): https://lists.fd.io/g/vpp-dev/message/19488
Mute This Topic: https://lists.fd.io/mt/83117335/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] "make install-ext-deps" failing w/ master/latest?

[Dave Barach]

Let me answer my own question:

 

$ /usr/bin/cmake --version

cmake version 3.16.3

 

Works.

 

$ /usr/local/bin/cmake.new --version

cmake version 3.19.xxx

 

Fails as shown below.

 

As in: cmake 3.19 appears not to support the "-target=quicly" argument...

 

FWIW... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach
Sent: Wednesday, May 12, 2021 10:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] "make install-ext-deps" failing w/ master/latest?

 

Any clue what this is all about?

 

--- validating quicly 0.1.3-vpp checksum

--- extracting quicly 0.1.3-vpp

--- patching quicly 0.1.3-vpp

Applying patch: 0001-cmake-install.patch

patching file CMakeLists.txt

Applying patch: 0002-cmake-install-picotls.patch

patching file deps/picotls/CMakeLists.txt

Applying patch: 0003-unused-is-late-ack.patch

patching file lib/quicly.c

--- configuring quicly 0.1.3-vpp - log:
/scratch/vpp-ext-deps/build/external/deb/_build/quicly.config.log

--- building quicly 0.1.3-vpp - log:
/scratch/vpp-ext-deps/build/external/deb/_build/quicly.build.log

CMake Error: Unknown argument --target=quicly

CMake Error: Run 'cmake --help' for all supported options.

make[5]: *** [packages/quicly.mk:48:
/scratch/vpp-ext-deps/build/external/deb/_build/.quicly.build.ok] Error 1

make[5]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make[4]: *** [debian/rules:25: override_dh_install] Error 2

make[4]: Leaving directory '/scratch/vpp-ext-deps/build/external/deb'

make[3]: *** [debian/rules:17: binary] Error 2

make[3]: Leaving directory '/scratch/vpp-ext-deps/build/external/deb'

dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
exit status 2

make[2]: *** [Makefile:75: vpp-ext-deps_21.06-8_amd64.deb] Error 2

make[2]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make[1]: *** [Makefile:82: install-deb] Error 2

make[1]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make: *** [Makefile:597: install-ext-deps] Error 2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19377): https://lists.fd.io/g/vpp-dev/message/19377
Mute This Topic: https://lists.fd.io/mt/82773115/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] "make install-ext-deps" failing w/ master/latest?

[Dave Barach]

Any clue what this is all about?

 

--- validating quicly 0.1.3-vpp checksum

--- extracting quicly 0.1.3-vpp

--- patching quicly 0.1.3-vpp

Applying patch: 0001-cmake-install.patch

patching file CMakeLists.txt

Applying patch: 0002-cmake-install-picotls.patch

patching file deps/picotls/CMakeLists.txt

Applying patch: 0003-unused-is-late-ack.patch

patching file lib/quicly.c

--- configuring quicly 0.1.3-vpp - log:
/scratch/vpp-ext-deps/build/external/deb/_build/quicly.config.log

--- building quicly 0.1.3-vpp - log:
/scratch/vpp-ext-deps/build/external/deb/_build/quicly.build.log

CMake Error: Unknown argument --target=quicly

CMake Error: Run 'cmake --help' for all supported options.

make[5]: *** [packages/quicly.mk:48:
/scratch/vpp-ext-deps/build/external/deb/_build/.quicly.build.ok] Error 1

make[5]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make[4]: *** [debian/rules:25: override_dh_install] Error 2

make[4]: Leaving directory '/scratch/vpp-ext-deps/build/external/deb'

make[3]: *** [debian/rules:17: binary] Error 2

make[3]: Leaving directory '/scratch/vpp-ext-deps/build/external/deb'

dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
exit status 2

make[2]: *** [Makefile:75: vpp-ext-deps_21.06-8_amd64.deb] Error 2

make[2]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make[1]: *** [Makefile:82: install-deb] Error 2

make[1]: Leaving directory '/scratch/vpp-ext-deps/build/external'

make: *** [Makefile:597: install-ext-deps] Error 2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19376): https://lists.fd.io/g/vpp-dev/message/19376
Mute This Topic: https://lists.fd.io/mt/82773115/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] What is the relationship between "struct vlib_frame_t" , "struct vlib_pending_frame_t" and "struct vlib_next_frame_t"? #vpp-dev

[Dave Barach]

The graph dispatch engine isn’t particularly mysterious. That having been 
written, it would be perfectly OK to assume that it works, save questions for 
later, and move on to learning how to use vpp to solve problems.

 

If you want or need to understand the graph dispatcher in minute detail, build 
a -g -O0 image, and watch exactly what happens when a certain node enqueues 
packets to its next nodes.  Specifically: vlib_get_next_frame_internal(), 
vlib_put_next_frame(), and dispatch_node() [in src/vlib/main.c].   

 

Q1: vlib_frame_t’s are rather general vector (plus scalar) containers. Vpp is 
not the only conceivable use of vlib. Vectors can have arbitrary (albeit 
uniform) vector element sizes. We use vlib_frame_t’s comprising 4-byte buffer 
indices in vpp.

 

A vlib_pending_frame_t is a graph dispatcher runtime queue element. Comments 
notwithstanding, vlib_pending_frame_t’s point at vlib_frame_t’s which are on 
the run-queue.

 

A vlib_next_frame_t is the runtime data structure used to implement a single 
graph arc. When you enqueue a packet to graph arc index i, infrastructure uses 
the index i to find the next_frame_t, which in turn points to the indicated 
vlib_frame_t. Read the code very carefully for more detail.

 

Q2: pending frames point at frames, as described above. 

 

Q3: each node has a SET of next_frame_t’s, which in turn (may) point to frames, 
or be empty (e.g. if no pkts have followed the indicated graph arc yet).

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Mohanty, Chandan 
(Nokia - IN/Bangalore)
Sent: Tuesday, May 11, 2021 2:42 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] What is the relationship between "struct vlib_frame_t" , 
"struct vlib_pending_frame_t" and "struct vlib_next_frame_t"? #vpp-dev

 

Hi Experts,
 I am new to VPP.I have gone through the Node despatcher Functionality at 
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html?highlight=dispatch#graph-node-dispatcher

However below queries are arising. Kindly help me on clarifying those.

 

Q1.

What is the relationship between "struct vlib_frame_t" , "struct 
vlib_pending_frame_t" and "struct vlib_next_frame_t"?

 

 

In the Node despatch section there is text as below 

"there are no guarantees that a pending frame will be processed immediately, 
which means that MORE packets may be added to the underlying vlib_frame_t ,

after It (?) has been attached to a vlib_pending_frame_t "

 

Q2.

Does this mean "vlib_frame_t" is placed inside "vlib_pending_frame_t".But from 
below structure description,it does not appear so.Kindly guide me here.

 

 

In the Node despatch section there is text as below

"Once a node finishes adding element to a frame, it will acquire a 
vlib_pending_frame_t and end up on the graph dispatcher’s RUN-QUEUE".

"Care must be taken to allocate new frames and pending frames if a 
(pending_frame, frame) PAIR  fills."

"Only one graph node at a time thinks it “owns” the target vlib_frame_t."

 

 

Q3.

Does this mean,each node has separate,independent (pending_frame, frame) PAIR?

 

Q4.

"Frame" is where all the other nodes send/place/put packet into. 
"pending_frame",is ,FROM,where the current node extracts/lifts packets and 
process?

But how "pending_frame" is replenished from "frame" or from somewhere,I am 
unable to understand.

 

 

Kindly Guide me on above queries.

 

 

 

 

typedef struct vlib_frame_t

{

  /* Frame flags. */

  u16 flags;

 

  /* Number of scalar bytes in arguments. */

  u8 scalar_size;

 

  /* Number of bytes per vector argument. */

  u8 vector_size;

 

  /* Number of vector elements currently in frame. */

  u16 n_vectors;

 

  /* Scalar and vector arguments to next node. */

  u8 arguments[0];

} vlib_frame_t;

 

 

 

typedef struct

{

  /* Node and runtime for this frame. */

  u32 node_runtime_index;

 

  /* Frame index (in the heap). */

  u32 frame_index;

 

  /* Start of next frames for this node. */

  u32 next_frame_index;

 

  /* Special value for next_frame_index when there is no next frame. */

#define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)

} vlib_pending_frame_t;

 

 

typedef struct

{

  /* Frame index. */

  u32 frame_index;

  /* Node runtime for this next. */

  u32 node_runtime_index;

  /* Next frame flags. */

  u32 flags;

  /* Reflects node frame-used flag for this next. */

#define VLIB_FRAME_NO_FREE_AFTER_DISPATCH \

  VLIB_NODE_FLAG_FRAME_NO_FREE_AFTER_DISPATCH

 

  /* This next frame owns enqueue to node

 corresponding to node_runtime_index. */

#define VLIB_FRAME_OWNER (1 << 15)

 

  /* Set when frame has been allocated for this next. */

#define VLIB_FRAME_IS_ALLOCATED VLIB_NODE_FLAG_IS_OUTPUT

 

  /* Set when frame has been added to pending vector. */

#define VLIB_FRAME_PENDING VLIB_NODE_FLAG_IS_DROP

 

Re: [vpp-dev] Clock time in pcap

[Dave Barach]

I wasn’t clear enough: your proposal uses a single clock object across multiple 
threads. The counters returned by the x86_64 rdtsc instruction are per-core, 
and differ by a noticeable fraction of a second...

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of 
srinimurth...@gmail.com
Sent: Friday, April 16, 2021 4:18 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Clock time in pcap

 

Hi Dave,
 Thanks! for the response.
My proposed changes are in pcap_add_packet, which is called from 
dispatch_pcap_trace and pcap_add_buffer after aquiring spin lock.
So, I think it's MT-safe.

Thanks,
Srini 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19226): https://lists.fd.io/g/vpp-dev/message/19226
Mute This Topic: https://lists.fd.io/mt/82117060/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] Feature Arcs

[Dave Barach]

Vnet_feature_arc_start initializes b->current_config_index and next0 if and
only if features are active on the arc. 

 

Take a look at src/vnet/ip/ip_punt_drop.h, which explicitly (and correctly!)
sets next0...next3 to zero, or src/vnet/dpo/dvr_dpo.c which sets next0..1 to
zero. As in: if no features are active on the arc, these codes (and
presumably any correct code) will send the packet to .next_nodes[0].

 

Up to the point where one calls e.g. vlib_validate_buffer_enqueue_xN() - or
vlib_buffer_enqueue_to_next() depending on dispatch style - the code can
change its mind about nextN. 

 

Do yourself a favor: build a -g -O0 image, configure some features e.g. on a
packet-generator interface, push packets into the head of the configured
feature arc, step through the head of feature arc and feature node code in
gdb. 

 

Look at the output of "show vlib graph" carefully. You'll see that the
feature code adds graph arcs with indices above those of static .next_node
arcs. 

 

D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of Catalin Vasile
Sent: Thursday, April 15, 2021 5:59 PM
To: v...@barachs.net; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Feature Arcs

 

Hi,

 

I've went through wiki before asking the questions.

 

2. Does ".next_nodes" from VLIB_REGISTER_NODE() restrain to which nodes the
.function() primitive may send it to?

>>> DB: explicit .next_nodes are used to divert packets off a given feature
arc. Typical use-case: send non-compliant frames to error-drop. The feature
arc mechanism adds additional next-node indices (next0..3 values) which
correspond to the next enabled feature on the feature arc. 

>>> CV: vnet_feature_arc_start() seems to actually trigger the send, and
there is a "next" argument that says explicitly where to send them. What
roles does the ".next_nodes" have if the programmer still explicitly tells
it? When you say "off a given feature arc" you are saying when the
traffic/packets start to get outside of that arc?

  _  

From: v...@barachs.net   mailto:v...@barachs.net> >
Sent: Thursday, April 15, 2021 14:47
To: Catalin Vasile mailto:catali...@radwin.com> >;
vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> >
Subject: RE: [vpp-dev] Feature Arcs 

 

Please see
https://fd.io/docs/vpp/master/gettingstarted/developers/featurearcs.html.
Also, see inline below

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Catalin Vasile
Sent: Thursday, April 15, 2021 6:17 AM
To: vpp-dev@lists.fd.io  
Subject: [vpp-dev] Feature Arcs

 

Hi,

 

I'm trying to grasp how features arcs are done in the code. And have a
couple of questions

 

1. Is a feature a representation of a node ? 

>>> DB: I would put it this way: nodes implement features

2. Does ".next_nodes" from VLIB_REGISTER_NODE() restrain to which nodes the
.function() primitive may send it to?

>>> DB: explicit .next_nodes are used to divert packets off a given feature
arc. Typical use-case: send non-compliant frames to error-drop. The feature
arc mechanism adds additional next-node indices (next0..3 values) which
correspond to the next enabled feature on the feature arc. 

 

3. I'm trying to grasp how the feature arhitecture has been thought. I
started by looking the "nsh" plugin.

>From what I understand:

VNET_FEATURE_ARC_INIT() creates an empty Arc of nodes/features

.start_nodes from VNET_FEATURE_ARC_INIT() says/adds where the Arc processing
starts

VNET_FEATURE_INIT() adds nodes/features to the Arc

.runs_before from VNET_FEATURE_INIT() and .next_nodes from
VLIB_REGISTER_NODE() give the vertices/dependencies in the Arc

 

Everything in "nsh" seems to start from the "nsh_midchain_node" node.

 

How is the "nsh_eth_output_node" triggered? I see it has the same name as
the Arc name ("nsh-eth-output"). Does this have any relevance or it is just
a coincidence of name? Does a node which belongs to no Arc get triggered
directly with no dependency?

4. It is not clear to me who initializes the "nm->output_feature_arc_index"
entry.

>>> DB: it is suspicious that the VNET_FEATURE_INIT(...) macro doesn't
include ".arc_index_ptr = _feature_arc_index":

 

/* Built-in nsh tx feature path definition */

VNET_FEATURE_INIT (nsh_interface_output, static) = {

  .arc_name = "nsh-eth-output",

  .node_name = "interface-output",

  .runs_before = 0, /* not before any other features */

};

 

Might ask the nsh maintainers [see /MAINTAINERS] about that. 

 

Best regards,

Catalin Vasile


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19218): https://lists.fd.io/g/vpp-dev/message/19218
Mute This Topic: https://lists.fd.io/mt/82113339/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] Clock time in pcap

[Dave Barach]

The proposed fix won’t work correctly with multiple threads. 

 

Instead, please address the issue in pcap_write(...) by adding an offset 
argument and passing the required offset as f64 seconds since the epoch:

 

   f64 seconds_since_vpp_started = vlib_time_now(vm);

   f64 seconds_since_the_epoch = unix_time_now();

   f64 vpp_start_time = seconds_since_the_epoch – seconds_since_vpp_started;

 

 

In the while-loop which writes out pm->pcap_data, add the supplied offset to 
each packet header timestamp. Simplest to convert the stored (sec,usec) data 
back to f64 seconds, add the supplied constant, then store as (sec,usec).

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of 
srinimurth...@gmail.com
Sent: Thursday, April 15, 2021 9:55 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Clock time in pcap

 

Hello Team,
   I observe that timestamp captured in pcap collected on VPP with below 
command captures the time since VPP started rather than the clock time.

"pcap trace rx tx max 1 intfc any file rxt.pcap"

Further looking into code(version 20.05), I observe that time since VPP 
restarted is being set.
Code reference below.

static inline void

pcap_add_buffer (pcap_main_t * pm,

 struct vlib_main_t *vm, u32 buffer_index,

 u32 n_bytes_in_trace)

{

  vlib_buffer_t *b = vlib_get_buffer (vm, buffer_index);

  u32 n = vlib_buffer_length_in_chain (vm, b);

  i32 n_left = clib_min (n_bytes_in_trace, n);

  f64 time_now = vlib_time_now (vm);   <<---

...
}

After modifying code as below, packets are timestamped with clock time.

src/vppinfra/pcap.h

++#include 

  /** Min/Max Packet bytes */

  u32 min_packet_bytes, max_packet_bytes;

 

  /** Time */

++  clib_timebase_t timebase;

} pcap_main_t;


src/vppinfra/pcap_funcs.h

pcap_add_packet()
{

 ++ vlib_main_t *vm = vlib_get_main();

 

 ++ if(!(pm->timebase.clib_time))

  ++{

  ++clib_timebase_init (&(pm->timebase), 0 /* GMT */ ,

   ++   CLIB_TIMEBASE_DAYLIGHT_NONE,

  ++>clib_time /* share the system clock */ );

++  }

++  time_now = clib_timebase_now(&(pm->timebase));

 

}

My questions below.
1)Currently in fdio version 20.05 packets captured in pcap are timestamped with 
the time since VPP restarted.
   Is this understanding correct?
2) If answer to above question is "YES", then is the fix correct?

Thanks,
Srini


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19215): https://lists.fd.io/g/vpp-dev/message/19215
Mute This Topic: https://lists.fd.io/mt/82117060/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] Feature Arcs

[Dave Barach]

Please see
https://fd.io/docs/vpp/master/gettingstarted/developers/featurearcs.html.
Also, see inline below

 

From: vpp-dev@lists.fd.io  On Behalf Of Catalin Vasile
Sent: Thursday, April 15, 2021 6:17 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Feature Arcs

 

Hi,

 

I'm trying to grasp how features arcs are done in the code. And have a
couple of questions

 

1. Is a feature a representation of a node ? 

>>> DB: I would put it this way: nodes implement features



2. Does ".next_nodes" from VLIB_REGISTER_NODE() restrain to which nodes the
.function() primitive may send it to?

>>> DB: explicit .next_nodes are used to divert packets off a given feature
arc. Typical use-case: send non-compliant frames to error-drop. The feature
arc mechanism adds additional next-node indices (next0..3 values) which
correspond to the next enabled feature on the feature arc. 

 

3. I'm trying to grasp how the feature arhitecture has been thought. I
started by looking the "nsh" plugin.

>From what I understand:

VNET_FEATURE_ARC_INIT() creates an empty Arc of nodes/features

.start_nodes from VNET_FEATURE_ARC_INIT() says/adds where the Arc processing
starts

VNET_FEATURE_INIT() adds nodes/features to the Arc

.runs_before from VNET_FEATURE_INIT() and .next_nodes from
VLIB_REGISTER_NODE() give the vertices/dependencies in the Arc

 

Everything in "nsh" seems to start from the "nsh_midchain_node" node.

 

How is the "nsh_eth_output_node" triggered? I see it has the same name as
the Arc name ("nsh-eth-output"). Does this have any relevance or it is just
a coincidence of name? Does a node which belongs to no Arc get triggered
directly with no dependency?

4. It is not clear to me who initializes the "nm->output_feature_arc_index"
entry.

>>> DB: it is suspicious that the VNET_FEATURE_INIT(...) macro doesn't
include ".arc_index_ptr = _feature_arc_index":

 

/* Built-in nsh tx feature path definition */

VNET_FEATURE_INIT (nsh_interface_output, static) = {

  .arc_name = "nsh-eth-output",

  .node_name = "interface-output",

  .runs_before = 0, /* not before any other features */

};

 

Might ask the nsh maintainers [see /MAINTAINERS] about that. 

 

Best regards,

Catalin Vasile


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19209): https://lists.fd.io/g/vpp-dev/message/19209
Mute This Topic: https://lists.fd.io/mt/82113339/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] New Committer Proposal

[Dave Barach]

+1... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion
via lists.fd.io
Sent: Wednesday, March 31, 2021 1:58 PM
To: vpp-dev 
Cc: Zhang, Roy Fan 
Subject: [vpp-dev] New Committer Proposal


Dear VPP Committers,

I would like to propose Roy Fan Zhang from Intel as a new VPP committer.
Fan made significant contributions to the VPP including the async crypto
infrastructure and crypto scheduler.
Beside that I found that Fan is active in the community, and willing to
help.

Please let me know if you agree/neutral/disagree with +1/0/-1 (committers
only please).

My +1 is here.

Thanks,

Damjan



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19070): https://lists.fd.io/g/vpp-dev/message/19070
Mute This Topic: https://lists.fd.io/mt/81756505/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 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

[Dave Barach]

Dear Elias,

Glad that you were able to switch, and that you're not seeing the issue 
anymore...

Thanks for letting me know... Dave

-Original Message-
From: Elias Rudberg  
Sent: Thursday, March 25, 2021 12:43 PM
To: v...@barachs.net; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 
in IPv4 Shallow Virtual reassembly code

Hello Dave,

Just to follow up on this, we switched from 20.09 to 21.01 and that indeed 
seems to have solved the problem for us, having now run for about a month 
without the issue coming back.

Thanks for your help!

Best regards,
Elias


On Sun, 2021-02-21 at 07:43 -0500, v...@barachs.net wrote:
> That's right. In 20.09, bihash did its own os-level memory allocation. 
> You could (probably) pick up and port src/vppinfra/bihash*.[ch] to 
> 20.09, or you could add some config knobs to the reassembly code.
> 
> If switching to 21.01 is an option, that seems like the path of least 
> resistance.
> 
> HTH... Dave
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Elias 
> Rudberg
> Sent: Friday, February 19, 2021 12:10 PM
> To: v...@barachs.net; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in
> clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code
> 
> Thanks Dave, however it looks like BIHASH_USE_HEAP does not exist in 
> VPP 20.09 but was introduced later. Looks like it appeared with the 
> commit 2454de2d4 "vppinfra: use heap to store bihash data" which was 
> after 20.09 was released.
> 
> I guess this means that bihash data is not stored on the heap in VPP 
> 20.09. Maybe switching to VPP 21.01 would help with this issue then, 
> or at least with 21.01 all of our main heap space would need to be 
> consumed before we get another os_out_of_memory() SIGABRT crash?
> 
> / Elias



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19027): https://lists.fd.io/g/vpp-dev/message/19027
Mute This Topic: https://lists.fd.io/mt/80753669/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] timer_expired_callback is not getting called after sometime

[Dave Barach]

Which version of vpp is involved? 

 

A while ago, I went to considerable trouble to idiot-proof the vpp timebase 
code [vlib_time_now()] against huge time jumps, particularly negative time 
jumps. The ntp daemon is perfectly capable of resetting the kernel’s idea of 
“now” by an hour or more in either direction. Your description is at least a 
potential match for an older version of vpp falling victim to a “Back to the 
Future” time jump.

 

At the point where timers stop expiring, use gdb to sanity-check “now” and 
“tw->next_run_time”: 

 

static inline

  u32 * TW (tw_timer_expire_timers_internal) (TWT (tw_timer_wheel) * tw,

  f64 now,

  u32 * callback_vector_arg)

{

 

  /* Called too soon to process new timer expirations? */

  if (PREDICT_FALSE (now < tw->next_run_time))

return callback_vector_arg;

 

HTH... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of hari_akkin via 
lists.fd.io
Sent: Wednesday, March 17, 2021 5:21 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] timer_expired_callback is not getting called after sometime

 

Hi,
I have tw implementation and its working fine for sometime and later the 
timer_expired_callback function is not  invoked even though the tw node is 
getting scheduled.
 
Detals:

tw_node of type VLIB_NODE_TYPE_INPUT.

Node function calls run_timer_wheels :
run_timer_wheels(vm)
{

tw_timer_wheel_1t_1w_2048sl_t* tw;

f64 now;

u32 thread_id = vlib_get_current_worker_index();

tw = _main->timer_wheels[thread_id];

now = vlib_time_now (vm);

tw_timer_expire_timers_1t_1w_2048sl(tw, now);

}

Init:


initialize_timer_wheels ()

{

.
.
tw_timer_wheel_1t_1w_2048sl_t* tw;

int i=0;

u32 n_workers = vlib_num_workers();

 

vec_validate (p_main->timer_wheels, n_workers-1);

 

for(i=0; itimer_wheels[i];

tw_timer_wheel_init_1t_1w_2048sl (tw, timer_expired_callback, 0.1, 
1024);

tw->last_run_time = vlib_time_now (vlib_get_main());

}

}

 

Start Function:


start_timer_wheels()

{

   
u32 n_workers = vlib_num_workers();

for(int i=0; istop_timer_handle[i] = 
tw_timer_start_1t_1w_2048sl(_main->timer_wheels[i],

   i 
/*elt-index*/,

   0 
/*timer-id*/,

   1 
/*interval*/);

}

return 0;

}

 

timer_expired_callback (u32 * expired_timers)

{


int i   = 0;

u32 thread_id   = 
vlib_get_current_worker_index();

vlib_main_t *vm = vlib_get_main();

f64 time_now= vlib_time_now(vm);

 

for (i = 0; i < vec_len (expired_timers); i++)

{

  /* application logic */

}

 

p_main->stop_timer_handle[thread_id] = 
tw_timer_start_1t_1w_2048sl(_main->timer_wheels[thread_id],


 thread_id,


0,


1);

}


Any thing I am missing here.

thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18952): https://lists.fd.io/g/vpp-dev/message/18952
Mute This Topic: https://lists.fd.io/mt/81398894/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] Unexpected behavior of Classifier

[Dave Barach]

You could try the buffer metadata tracking plugin, which should tell you which 
buffer metadata fields are touched in the graph trajectory you're using. 

I haven't tested it in a long time, so "caveat emptor."

FWIW... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne 
(bganne) via lists.fd.io
Sent: Tuesday, March 16, 2021 6:21 AM
To: jerome.bay...@student.uliege.be; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Unexpected behavior of Classifier

Hi Jerome,

Thanks. If I understand the issue correctly, what you are observing is the 
classifier does set the correct value in the ip6-inacl node but by the time the 
packet hits the ip6-hop-by-hop node, this value has been overwritten.
If this is correct, the most likely culprit is the union in vnet_opaque_t 
structure have changed, and you should be able to pinpoint where it gets 
overwritten and why by using hardware watchpoint. For example in gdb, we can 
put a breakpoint right after the opaque_index is set in ip6-inacl node and then 
put a watchpoint on the opaque_index location. When it is overwritten later, 
the watchpoint should break in gdb and you should see why:
~# gdb -p $(pidof gdb)
(gdb) l src/vnet/ip/ip_in_out_acl.c:642
637
638   e0 = vnet_classify_find_entry_inline (t0, (u8 *) h0, hash0, 
now);
639   if (e0)
640 {
641   vnet_buffer (b[0])->l2_classify.opaque_index = 
e0->opaque_index;
642   vlib_buffer_advance (b[0], e0->advance);
643
644   next0 = (e0->next_index < n_next_nodes) ?
645 e0->next_index : next0;
646
(gdb) b src/vnet/ip/ip_in_out_acl.c:642
(gdb) continue

... Inject 1 packet with bad behavior.
... gdb should break in ip6-inacl node right after the opaque_index is set.

(gdb) watch -l vb(b[0])->l2_classify.opaque_index
(gdb) continue

... Hopefully the watchpoint will break when opaque_index is overwritten and 
you can see the offensive line.

Hope this helps,
ben

> -Original Message-
> From: jerome.bay...@student.uliege.be 
> 
> Sent: lundi 15 mars 2021 12:35
> To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io
> Subject: Re: Unexpected behavior of Classifier
> 
> Hello Benoit,
> 
> Here is the packet trace I gathered :
> 
> Packet 1
> 
> 00:00:09:235345: memif-input
>   memif: hw_if_index 1 next-index 4
> slot: ring 0
> 00:00:09:235349: ethernet-input
>   IP6: 02:fe:94:4a:87:eb -> 02:fe:ea:c3:43:da
> 00:00:09:235368: ip6-input
>   IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2
> tos 0x00, flow label 0x0, hop limit 253, payload length 132
> 00:00:09:235384: ip6-inacl
>   INACL: sw_if_index 1, next_index 1, table 0, offset 1216
> 00:00:09:235412: ip6-lookup
>   fib 0 dpo-idx 7 flow hash: 0x
>   IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2
> tos 0x00, flow label 0x0, hop limit 253, payload length 132
> 00:00:09:235431: ip6-hop-by-hop
>   IP6_HOP_BY_HOP: next index 5 len 56 traced 56 namespace id 2, trace 
> type 0x1f, 0 elts left, 20 bytes per node
> [0], ttl: 0xfd, node id short: 0x2, ingress sw: 1, egress sw: 2, 
> timestamp (s): 0x604f458d, timestamp (sub-sec): 0x604f458d, transit 
> delay
> (ns): 0x
> [1], ttl: 0xfe, node id short: 0x1, ingress sw: 1, egress sw: 2, 
> timestamp (s): 0x604f458d, timestamp (sub-sec): 0x604f458d, transit 
> delay
> (ns): 0x
> 00:00:09:235450: ip6-rewrite
>   tx_sw_if_index 2 adj-idx 7 : ipv6 via db02::2 memif2/0: mtu:9000
> next:4
> flags:
> [] 02fe538a6ec702fe95c9987b86dd flow hash: 0x
>   :
> 02fe538a6ec702fe95c9987b86dd608400fcdb00
>   0020:
> 0001db0200023a06313200010002
>   0040:
> 28001f00fd0200010002604f458d604f458dfe010001
>   0060: 0002604f458d604f458d80007dfe8a310001c7014ba24516
> 00:00:09:235470: memif2/0-output
>   memif2/0
>   IP6: 02:fe:95:c9:98:7b -> 02:fe:53:8a:6e:c7
>   IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2
> tos 0x00, flow label 0x0, hop limit 252, payload length 132
> 
> You will maybe notice some differences on your side if you tried to 
> run traffic that includes IOAM data because I used a "fresh"
> implementation of IOAM I worked on these last months with another 
> person. Anyway, the issue I talked about is still present as you can 
> see it in the packet trace here above and it was also present before we 
> modified IOAM implementation.
> 
> I was not able to perform the test with the "old" IOAM implementation 
> (i.e the one still present currently in VPP repo) because it does not 
> seem to work anymore in recent VPP releases..
> 
> 
> 
> De: "Benoit Ganne (bganne)" 
> À: "jerome bayaux" ,
> vpp-dev@lists.fd.io
> Envoyé: Vendredi 12 Mars 2021 15:35:28
> Objet: RE: Unexpected behavior of Classifier
> 
> 
> Hi Jerome,
> 
> Could you share a packet trace of a packet that is being classified 
> but not correctly redirected? Eg. if you use 

Re: [vpp-dev] RFC: vlib_global_main_t

[Dave Barach]

Looks like a win to me...

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Thursday, March 11, 2021 9:36 AM
To: vpp-dev 
Subject: [vpp-dev] RFC: vlib_global_main_t



Guys,

I found that having both global and thread data in vlib_main_t  is confusing to 
many people and also bug prone.

I wonder if there is sense in. moving global data to new vlib_global_main_t?

I submitted RFC patch and would like to hear what people think about that….

https://gerrit.fd.io/r/c/vpp/+/31623

Thanks,

Damjan



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18899): https://lists.fd.io/g/vpp-dev/message/18899
Mute This Topic: https://lists.fd.io/mt/81253828/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 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

[Dave Barach]

That's right. In 20.09, bihash did its own os-level memory allocation. You 
could (probably) pick up and port src/vppinfra/bihash*.[ch] to 20.09, or you 
could add some config knobs to the reassembly code. 

If switching to 21.01 is an option, that seems like the path of least 
resistance.

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Elias Rudberg
Sent: Friday, February 19, 2021 12:10 PM
To: v...@barachs.net; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 
in IPv4 Shallow Virtual reassembly code

Thanks Dave, however it looks like BIHASH_USE_HEAP does not exist in VPP 20.09 
but was introduced later. Looks like it appeared with the commit 2454de2d4 
"vppinfra: use heap to store bihash data" which was after 20.09 was released.

I guess this means that bihash data is not stored on the heap in VPP 20.09. 
Maybe switching to VPP 21.01 would help with this issue then, or at least with 
21.01 all of our main heap space would need to be consumed before we get 
another os_out_of_memory() SIGABRT crash?

/ Elias


On Fri, 2021-02-19 at 09:56 -0500, v...@barachs.net wrote:
> See ../src/vppinfra/bihash_16_8.h:
> 
> #define BIHASH_USE_HEAP 1
> 
> The the sv reassembly bihash table configuration appears to be 
> hardwired, and complex enough to satisfy the cash customers. If the 
> number of buckets is way too low for your use-case, bihash is capable 
> of wasting a considerable amount of memory.
> 
> Suggest that you ping Klement Sekera, it's his code...
> 
> D.
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Elias 
> Rudberg
> Sent: Friday, February 19, 2021 7:41 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] VPP 20.09 os_out_of_memory() in
> clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code
> 
> Hello VPP experts,
> 
> We have a problem with VPP 20.09 crashing with SIGABRT, this happened 
> several times lately but we do not have an exact way of reproducing 
> it. Here is a backtrace from gdb:
> 
> Thread 10 "vpp_wk_7" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7feac47f8700 (LWP 6263)] __GI_raise (
> sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #0  __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x74044921 in __GI_abort () at abort.c:79
> #2  0xc640 in os_panic () at src/vpp/vnet/main.c:368
> #3  0x77719229 in alloc_aligned_16_8 (h=0x77b79990 
> , nbytes=) at
> src/vppinfra/bihash_template.c:34
> #4  0x7771b650 in value_alloc_16_8 (h=0x77b79990 
> , log2_pages=4) at
> src/vppinfra/bihash_template.c:356
> #5  0x7771b43a in split_and_rehash_16_8 (h=0x77b79990 
> , old_values=0x7ff87c7b0d40, old_log2_pages=3,
> new_log2_pages=4) at src/vppinfra/bihash_template.c:453
> #6  0x77710f84 in clib_bihash_add_del_inline_with_hash_16_8
> (h=0x77b79990 , add_v=0x7ffbf2088c60, 
> hash=, is_add=, is_stale_cb=0x0,
> arg=0x0) at src/vppinfra/bihash_template.c:765
> #7  clib_bihash_add_del_inline_16_8 (h=0x77b79990 
> , add_v=0x7ffbf2088c60, is_add=, 
> is_stale_cb=0x0, arg=0x0) at src/vppinfra/bihash_template.c:857
> #8  clib_bihash_add_del_16_8 (h=0x77b79990 , 
> add_v=0x7ffbf2088c60, is_add=) at
> src/vppinfra/bihash_template.c:864
> #9  0x766795ec in ip4_sv_reass_find_or_create (vm= out>, rm=, rt=, kv=,
> do_handoff=) at src/vnet/ip/reass/ip4_sv_reass.c:364
> #10 ip4_sv_reass_inline (vm=, node=, 
> frame=, is_feature=255, is_output_feature=false,
> is_custom=false) at src/vnet/ip/reass/ip4_sv_reass.c:726
> #11 ip4_sv_reass_node_feature_fn_skx (vm=, 
> node=, frame=) at
> src/vnet/ip/reass/ip4_sv_reass.c:919
> #12 0x75ac806e in dispatch_node (vm=0x7ffbf1e74400, 
> node=0x7ffbf2553fc0, type=VLIB_NODE_TYPE_INTERNAL, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
> last_time_stamp=) at src/vlib/main.c:1194
> #13 dispatch_pending_node (vm=0x7ffbf1e74400, 
> pending_frame_index=, last_time_stamp=) 
> at src/vlib/main.c:1353
> #14 vlib_main_or_worker_loop (vm=0x7ffbf1e74400, is_main=0) at
> src/vlib/main.c:1846
> #15 vlib_worker_loop (vm=0x7ffbf1e74400) at src/vlib/main.c:1980
> 
> The line at bihash_template.c:34 is "os_out_of_memory ()".
> 
> If VPP calls "os_out_of_memory()" at that point in the code, what does 
> that mean, is there some way we could configure VPP to allow it to use 
> more memory for this kind of allocations?
> 
> We have plenty of physical memory available and the main heap 
> ("heapsize" in startup.conf) has already been set to a large value but 
> maybe this part of the code is using some other kind of memory 
> allocation, not using the main heap? How do we know if this particular 
> allocation is using the main heap or not?
> 
> Best regards,
> Elias
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18775): https://lists.fd.io/g/vpp-dev/message/18775
Mute This Topic: 

Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

[Dave Barach]

See ../src/vppinfra/bihash_16_8.h:

#define BIHASH_USE_HEAP 1

The the sv reassembly bihash table configuration appears to be hardwired, and 
complex enough to satisfy the cash customers. If the number of buckets is way 
too low for your use-case, bihash is capable of wasting a considerable amount 
of memory.

Suggest that you ping Klement Sekera, it's his code...

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Elias Rudberg
Sent: Friday, February 19, 2021 7:41 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in 
IPv4 Shallow Virtual reassembly code

Hello VPP experts,

We have a problem with VPP 20.09 crashing with SIGABRT, this happened several 
times lately but we do not have an exact way of reproducing it. Here is a 
backtrace from gdb:

Thread 10 "vpp_wk_7" received signal SIGABRT, Aborted.
[Switching to Thread 0x7feac47f8700 (LWP 6263)] __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#0  __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x74044921 in __GI_abort () at abort.c:79
#2  0xc640 in os_panic () at src/vpp/vnet/main.c:368
#3  0x77719229 in alloc_aligned_16_8 (h=0x77b79990 
, nbytes=) at
src/vppinfra/bihash_template.c:34
#4  0x7771b650 in value_alloc_16_8 (h=0x77b79990 
, log2_pages=4) at
src/vppinfra/bihash_template.c:356
#5  0x7771b43a in split_and_rehash_16_8 (h=0x77b79990 
, old_values=0x7ff87c7b0d40, old_log2_pages=3,
new_log2_pages=4) at src/vppinfra/bihash_template.c:453
#6  0x77710f84 in clib_bihash_add_del_inline_with_hash_16_8
(h=0x77b79990 , add_v=0x7ffbf2088c60, hash=, is_add=, is_stale_cb=0x0, arg=0x0) at 
src/vppinfra/bihash_template.c:765
#7  clib_bihash_add_del_inline_16_8 (h=0x77b79990 , 
add_v=0x7ffbf2088c60, is_add=, is_stale_cb=0x0, arg=0x0) at 
src/vppinfra/bihash_template.c:857
#8  clib_bihash_add_del_16_8 (h=0x77b79990 , 
add_v=0x7ffbf2088c60, is_add=) at
src/vppinfra/bihash_template.c:864
#9  0x766795ec in ip4_sv_reass_find_or_create (vm=, rm=, rt=, kv=,
do_handoff=) at src/vnet/ip/reass/ip4_sv_reass.c:364
#10 ip4_sv_reass_inline (vm=, node=, 
frame=, is_feature=255, is_output_feature=false,
is_custom=false) at src/vnet/ip/reass/ip4_sv_reass.c:726
#11 ip4_sv_reass_node_feature_fn_skx (vm=, node=, 
frame=) at
src/vnet/ip/reass/ip4_sv_reass.c:919
#12 0x75ac806e in dispatch_node (vm=0x7ffbf1e74400, 
node=0x7ffbf2553fc0, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
last_time_stamp=) at src/vlib/main.c:1194
#13 dispatch_pending_node (vm=0x7ffbf1e74400, pending_frame_index=, last_time_stamp=) at src/vlib/main.c:1353
#14 vlib_main_or_worker_loop (vm=0x7ffbf1e74400, is_main=0) at
src/vlib/main.c:1846
#15 vlib_worker_loop (vm=0x7ffbf1e74400) at src/vlib/main.c:1980

The line at bihash_template.c:34 is "os_out_of_memory ()".

If VPP calls "os_out_of_memory()" at that point in the code, what does that 
mean, is there some way we could configure VPP to allow it to use more memory 
for this kind of allocations?

We have plenty of physical memory available and the main heap ("heapsize" in 
startup.conf) has already been set to a large value but maybe this part of the 
code is using some other kind of memory allocation, not using the main heap? 
How do we know if this particular allocation is using the main heap or not?

Best regards,
Elias


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18771): https://lists.fd.io/g/vpp-dev/message/18771
Mute This Topic: https://lists.fd.io/mt/80753669/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] Make test failures on ubuntu-20.04 AARCH64

[Dave Barach]

To make the pain go away, I quadrupled the vapi timeout for the bihash test 
vectors. Turns out that a couple of tests run for almost 5 seconds (on aarch64, 
debug) which caused sporadic failures.

 

That’s probably about the right size hammer for this specific problem. 

 

FWIW... Dave

 

From: vpp-dev@lists.fd.io  On Behalf Of Paul Vinciguerra
Sent: Tuesday, February 9, 2021 1:31 PM
To: Dave Barach 
Cc: Benoit Ganne (bganne) ; Ole Troan ; 
Dave Wallace ; vpp-dev ; Juraj 
Linkeš 
Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

 

Hi Dave,

 

test_cli.py verifies the timeout checking code is working.  

 

The groundwork to clean up the framework can be found here.  [0]

 

The test framework cannot distinguish between a timeout and a more serious 
problem, so for now we assume vpp has died.

 

For test, I would have liked to do something similar to what you do with 
growing your vectors.  If it is a true Timeout, rerun the test with say 3/2 the 
failing value and output the timeout with the run.  

 

We could have the testcases use different values for arm, but when load or hw 
specs change, the tests will break again.

 

Paul

 

[0] https://gerrit.fd.io/r/c/vpp/+/24085  

 

 

 

On Tue, Feb 9, 2021 at 8:37 AM Dave Barach mailto:v...@barachs.net> > wrote:

On aarch64, "make TEST=test_bihash test-debug" involves a debug CLI timeout 
which is right on the hairy edge of being too short. 

 

05:29:45,470 Calling cli_inband('cmd':'test bihash threads 2 nbuckets 64000 
careful 0 verbose 0\n','context':2,'_vl_msg_id':574)

05:29:45,471 TIMEOUT:: 5

 

This seems like the right incantation to fix it in 
src/vppinfra/test/test_bihash.py, but apparently it is not:

 

error = self.vapi.cli("test bihash threads 2 nbuckets" +

  " 64000 careful 0 verbose 0", timeout=15)

 

Please advise... Thanks... Dave

 

-Original Message-
From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Benoit Ganne (bganne) via 
lists.fd.io <http://lists.fd.io> 
Sent: Tuesday, February 9, 2021 8:06 AM
To: Dave Barach mailto:v...@barachs.net> >; 'Ole Troan' 
mailto:otr...@employees.org> >; 'Dave Wallace' 
mailto:dwallac...@gmail.com> >; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> 
Cc: 'Juraj Linkeš' mailto:juraj.lin...@pantheon.tech> >
Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

 

I am going to have a look at IKE.

 

In case it is useful to others, thanks to QEMU you can run a Ubuntu 20.04 ARM 
docker container on your x86 workstation:

 

# step 0: add support for multiarch (must be done once after reboot) docker run 
--rm --privileged multiarch/qemu-user-static --reset --persistent yes 
--credential yes

 

# step 1: create your chroot (must be done once - I am sharing my homedir with 
my chroot and same UID/GID) docker run --name aarch64_u2004 --privileged --net 
host -v $HOME:$HOME -v /dev:/dev -td arm64v8/ubuntu:20.04 /bin/bash

 

# step 2: update and add user inside container docker container exec 
aarch64_u2004 sh -c "apt -qy update && apt dist-upgrade -qy && apt install -qy 
vim sudo make git && groupadd -g $(id -rg) $USER && useradd -u $(id -ru) -g 
$(id -rg) -M -d $HOME -s /bin/bash $USER && echo '$USER ALL=(ALL) NOPASSWD:ALL' 
>> /etc/sudoers && echo aarch64_u2004 > /etc/debian_chroot"

 

# step 3: log into ARM chroot

docker container exec -it aarch64_deb10 /bin/login -f $USER

 

Best

ben

 

> -Original Message-

> From:  <mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io < 
> <mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io> On Behalf Of Dave 

> Barach

> Sent: mardi 9 février 2021 12:47

> To: 'Ole Troan' < <mailto:otr...@employees.org> otr...@employees.org>; 'Dave 
> Wallace'

> < <mailto:dwallac...@gmail.com> dwallac...@gmail.com>;  
> <mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io

> Cc: 'Juraj Linkeš' < <mailto:juraj.lin...@pantheon.tech> 
> juraj.lin...@pantheon.tech>

> Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

> 

> Would be glad to take a look at the aarch64 bihash failure, modulo the 

> fact that the LF data center resources I've used before seem to have 

> had their credentials changed.

> 

> Please unicast appropriate (ip, userid, password) tuples.

> 

> Thanks... Dave

> 

> ssh  <mailto:vppdev@10.30.51.65> vppdev@10.30.51.65

> Warning: Permanently added '10.30.51.65' (ECDSA) to the list of known 

> hosts.

>  <mailto:vppdev@10.30.51.65's> vppdev@10.30.51.65's password:

> Permission denied, please try again.

>  <mailto:vppdev@10.30.51.65's> vppdev@10.30.51.65's password:

> Permission denied, please try again.

Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

[Dave Barach]

On aarch64, "make TEST=test_bihash test-debug" involves a debug CLI timeout
which is right on the hairy edge of being too short. 

 

05:29:45,470 Calling cli_inband('cmd':'test bihash threads 2 nbuckets 64000
careful 0 verbose 0\n','context':2,'_vl_msg_id':574)

05:29:45,471 TIMEOUT:: 5

 

This seems like the right incantation to fix it in
src/vppinfra/test/test_bihash.py, but apparently it is not:

 

error = self.vapi.cli("test bihash threads 2 nbuckets" +

  " 64000 careful 0 verbose 0", timeout=15)

 

Please advise... Thanks... Dave

 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne
(bganne) via lists.fd.io
Sent: Tuesday, February 9, 2021 8:06 AM
To: Dave Barach ; 'Ole Troan' ; 'Dave
Wallace' ; vpp-dev@lists.fd.io
Cc: 'Juraj Linkeš' 
Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

 

I am going to have a look at IKE.

 

In case it is useful to others, thanks to QEMU you can run a Ubuntu 20.04
ARM docker container on your x86 workstation:

 

# step 0: add support for multiarch (must be done once after reboot) docker
run --rm --privileged multiarch/qemu-user-static --reset --persistent yes
--credential yes

 

# step 1: create your chroot (must be done once - I am sharing my homedir
with my chroot and same UID/GID) docker run --name aarch64_u2004
--privileged --net host -v $HOME:$HOME -v /dev:/dev -td arm64v8/ubuntu:20.04
/bin/bash

 

# step 2: update and add user inside container docker container exec
aarch64_u2004 sh -c "apt -qy update && apt dist-upgrade -qy && apt install
-qy vim sudo make git && groupadd -g $(id -rg) $USER && useradd -u $(id -ru)
-g $(id -rg) -M -d $HOME -s /bin/bash $USER && echo '$USER ALL=(ALL)
NOPASSWD:ALL' >> /etc/sudoers && echo aarch64_u2004 > /etc/debian_chroot"

 

# step 3: log into ARM chroot

docker container exec -it aarch64_deb10 /bin/login -f $USER

 

Best

ben

 

> -Original Message-

> From:  <mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io <
<mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io> On Behalf Of Dave 

> Barach

> Sent: mardi 9 février 2021 12:47

> To: 'Ole Troan' < <mailto:otr...@employees.org> otr...@employees.org>;
'Dave Wallace'

> < <mailto:dwallac...@gmail.com> dwallac...@gmail.com>;
<mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io

> Cc: 'Juraj Linkeš' < <mailto:juraj.lin...@pantheon.tech>
juraj.lin...@pantheon.tech>

> Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

> 

> Would be glad to take a look at the aarch64 bihash failure, modulo the 

> fact that the LF data center resources I've used before seem to have 

> had their credentials changed.

> 

> Please unicast appropriate (ip, userid, password) tuples.

> 

> Thanks... Dave

> 

> ssh  <mailto:vppdev@10.30.51.65> vppdev@10.30.51.65

> Warning: Permanently added '10.30.51.65' (ECDSA) to the list of known 

> hosts.

>  <mailto:vppdev@10.30.51.65's> vppdev@10.30.51.65's password:

> Permission denied, please try again.

>  <mailto:vppdev@10.30.51.65's> vppdev@10.30.51.65's password:

> Permission denied, please try again.

>  <mailto:vppdev@10.30.51.65's> vppdev@10.30.51.65's password:

> Received disconnect from 10.30.51.65 port 22:2: Too many 

> authentication failures Disconnected from 10.30.51.65 port 22 $ ssh 

>  <mailto:vppdev@10.30.51.68> vppdev@10.30.51.68

> Warning: Permanently added '10.30.51.68' (ECDSA) to the list of known 

> hosts.

>  <mailto:vppdev@10.30.51.68's> vppdev@10.30.51.68's password:

> Permission denied, please try again.

>  <mailto:vppdev@10.30.51.68's> vppdev@10.30.51.68's password:

> Permission denied, please try again.

>  <mailto:vppdev@10.30.51.68's> vppdev@10.30.51.68's password:

> Received disconnect from 10.30.51.68 port 22:2: Too many 

> authentication failures Disconnected from 10.30.51.68 port 22

> 

> -Original Message-

> From:  <mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io <
<mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io> On Behalf Of Ole Troan

> Sent: Tuesday, February 9, 2021 5:20 AM

> To: Dave Wallace < <mailto:dwallac...@gmail.com> dwallac...@gmail.com>;
<mailto:vpp-dev@lists.fd.io> vpp-dev@lists.fd.io

> Cc: Juraj Linkeš < <mailto:juraj.lin...@pantheon.tech>
juraj.lin...@pantheon.tech>

> Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

> 

> And just to be clear, the failing tests are in the QUIC, bihash and 

> IKEv2 features.

> 

> > [4]

>  <https://logs.fd.io/sandbox/vex-yul-rot-jenkins-2/daw_30773_31019-vpp->
https://logs.fd.io/sandbox/vex-yul-rot-jenkins-2/daw_30773_

Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

[Dave Barach]

Would be glad to take a look at the aarch64 bihash failure, modulo the fact
that the LF data center resources I've used before seem to have had their
credentials changed.

Please unicast appropriate (ip, userid, password) tuples.

Thanks... Dave 

ssh vppdev@10.30.51.65
Warning: Permanently added '10.30.51.65' (ECDSA) to the list of known hosts.
vppdev@10.30.51.65's password: 
Permission denied, please try again.
vppdev@10.30.51.65's password: 
Permission denied, please try again.
vppdev@10.30.51.65's password: 
Received disconnect from 10.30.51.65 port 22:2: Too many authentication
failures
Disconnected from 10.30.51.65 port 22
$ ssh vppdev@10.30.51.68
Warning: Permanently added '10.30.51.68' (ECDSA) to the list of known hosts.
vppdev@10.30.51.68's password: 
Permission denied, please try again.
vppdev@10.30.51.68's password: 
Permission denied, please try again.
vppdev@10.30.51.68's password: 
Received disconnect from 10.30.51.68 port 22:2: Too many authentication
failures
Disconnected from 10.30.51.68 port 22

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ole Troan
Sent: Tuesday, February 9, 2021 5:20 AM
To: Dave Wallace ; vpp-dev@lists.fd.io
Cc: Juraj Linkeš 
Subject: Re: [vpp-dev] Make test failures on ubuntu-20.04 AARCH64

And just to be clear, the failing tests are in the QUIC, bihash and IKEv2
features.

> [4]
https://logs.fd.io/sandbox/vex-yul-rot-jenkins-2/daw_30773_31019-vpp-verify-
master-ubuntu2004-aarch64/4/
> vpp-unittest-QUICEchoIntMStreamTestCase-f5ywwo0l-FAILED
> vpp-unittest-TestBihash-_iohsbtr-FAILED
> vpp-unittest-TestInitiatorDelSAFromResponder-dgqdg78o-FAILED
> vpp-unittest-TestInitiatorKeepaliveMsg-0vo66yj2-FAILED
> vpp-unittest-TestInitiatorNATT-edyneyju-FAILED
> vpp-unittest-TestInitiatorPsk-m3vrysyi-FAILED
> vpp-unittest-TestInitiatorRekey-7lrb0f8t-FAILED
> vpp-unittest-TestInitiatorRequestWindowSize-4y4stlww-FAILED
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18705): https://lists.fd.io/g/vpp-dev/message/18705
Mute This Topic: https://lists.fd.io/mt/80495347/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_put_frame_to_node to udp-encap causes main-thread crash

[Dave Barach]

I’m in the process of adding a few ASSERTs() to catch this issue. Stay tuned...

 

D.

 

From: PRANAB DAS  
Sent: Sunday, February 7, 2021 1:40 PM
To: v...@barachs.net
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vlib_put_frame_to_node to udp-encap causes main-thread 
crash

 

Thanks Dave, it was a rookie mistake. 

Is there a way to turn on VNET debug flags to detect these kinds of errors?

 

Thank you very much.

 

- Pranab K Das

 

 

On Sat, Feb 6, 2021 at 6:24 AM mailto:v...@barachs.net> > 
wrote:

Make sure that vm = vlib_mains [thread_index], not vm = vlib_mains[0] = 
_global_main. 

 

>From what you wrote, I suspect that’s the problem.

 

D. 

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of PRANAB DAS
Sent: Friday, February 5, 2021 7:38 PM
To: vpp-dev@lists.fd.io  
Subject: [vpp-dev] vlib_put_frame_to_node to udp-encap causes main-thread crash

 

Hi

 

I am puzzled by the crash in the main-thread caused by the following code 
snippet that I have used to send control message payload over a udp encap 
tunnel. The udp encap tunnel is created using udp encap vppcli. The code below 
works when only a few packets are sent. But when I tried to send a burst of 
these messages, for instance in a for loop with count 10 it causes a crash on 
the main-thread even though the call is made on a worker thread.  

 

Really appreciate it you could provide some information how to debug this.

 

Thank you

 

if (vlib_buffer_alloc (vm, , 1) != 1)
{
return -1;
}

b0 = vlib_get_buffer (vm, bi0);

udp4_encap_node = vlib_get_node_by_name(vm, (u8 *) "udp4-encap");
dp4_encap_node_index=udp4_encap_node->index;

vnet_buffer(b0)->sw_if_index[VLIB_RX] = 0;
vnet_buffer(b0)->ip.adj_index[VLIB_TX] = 0; // udp encap tunnel created with 
index 0

vlib_frame_t *f = vlib_get_frame_to_node(vm, udp4_encap_node_index);
u32 *to_next = vlib_frame_vector_args(f);
to_next[0] = bi0;
f->n_vectors = 1;
vlib_put_frame_to_node(vm, udp4_encap_node_index, f);

 

This is the back trace. I don't understand how vlib_put_frame_to_node on a 
worker thread can trigger a crash on the main thread. Is it caused by some 
corruption ?



Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
dispatch_pending_node (vm=vm@entry=0x7f55e8b94300 , 
pending_frame_index=pending_frame_index@entry=3, 
last_time_stamp=510933815354328)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:1500
1500  nf->flags |= VLIB_FRAME_IS_ALLOCATED;
(gdb) bt
#0  dispatch_pending_node (vm=vm@entry=0x7f55e8b94300 , 
pending_frame_index=pending_frame_index@entry=3, 
last_time_stamp=510933815354328)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:1500
#1  0x7f55e8938bf6 in vlib_main_or_worker_loop (is_main=1, 
vm=0x7f55e8b94300 )
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2013
#2  vlib_main_loop (vm=0x7f55e8b94300 ) at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2141
#3  vlib_main (vm=, vm@entry=0x7f55e8b94300 , 
input=input@entry=0x7f55a7fd6fa0)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2387
#4  0x7f55e8978c46 in thread0 (arg=140006953403136) at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/unix/main.c:673
#5  0x7f55e80243dc in clib_calljmp () from /lib64/libvppinfra.so.20.05.1
#6  0x7ffd742d0920 in ?? ()
#7  0x7f55e8979ced in vlib_unix_main (argc=, argv=)
at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/unix/main.c:745


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18695): https://lists.fd.io/g/vpp-dev/message/18695
Mute This Topic: https://lists.fd.io/mt/80421445/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_put_frame_to_node to udp-encap causes main-thread crash

[Dave Barach]

Make sure that vm = vlib_mains [thread_index], not vm = vlib_mains[0] = 
_global_main. 

 

>From what you wrote, I suspect that’s the problem.

 

D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of PRANAB DAS
Sent: Friday, February 5, 2021 7:38 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_put_frame_to_node to udp-encap causes main-thread crash

 

Hi

 

I am puzzled by the crash in the main-thread caused by the following code 
snippet that I have used to send control message payload over a udp encap 
tunnel. The udp encap tunnel is created using udp encap vppcli. The code below 
works when only a few packets are sent. But when I tried to send a burst of 
these messages, for instance in a for loop with count 10 it causes a crash on 
the main-thread even though the call is made on a worker thread.  

 

Really appreciate it you could provide some information how to debug this.

 

Thank you

 

if (vlib_buffer_alloc (vm, , 1) != 1)
{
return -1;
}

b0 = vlib_get_buffer (vm, bi0);

udp4_encap_node = vlib_get_node_by_name(vm, (u8 *) "udp4-encap");
dp4_encap_node_index=udp4_encap_node->index;

vnet_buffer(b0)->sw_if_index[VLIB_RX] = 0;
vnet_buffer(b0)->ip.adj_index[VLIB_TX] = 0; // udp encap tunnel created with 
index 0

vlib_frame_t *f = vlib_get_frame_to_node(vm, udp4_encap_node_index);
u32 *to_next = vlib_frame_vector_args(f);
to_next[0] = bi0;
f->n_vectors = 1;
vlib_put_frame_to_node(vm, udp4_encap_node_index, f);

 

This is the back trace. I don't understand how vlib_put_frame_to_node on a 
worker thread can trigger a crash on the main thread. Is it caused by some 
corruption ?



Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
dispatch_pending_node (vm=vm@entry=0x7f55e8b94300 , 
pending_frame_index=pending_frame_index@entry=3, 
last_time_stamp=510933815354328)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:1500
1500  nf->flags |= VLIB_FRAME_IS_ALLOCATED;
(gdb) bt
#0  dispatch_pending_node (vm=vm@entry=0x7f55e8b94300 , 
pending_frame_index=pending_frame_index@entry=3, 
last_time_stamp=510933815354328)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:1500
#1  0x7f55e8938bf6 in vlib_main_or_worker_loop (is_main=1, 
vm=0x7f55e8b94300 )
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2013
#2  vlib_main_loop (vm=0x7f55e8b94300 ) at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2141
#3  vlib_main (vm=, vm@entry=0x7f55e8b94300 , 
input=input@entry=0x7f55a7fd6fa0)
at /usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/main.c:2387
#4  0x7f55e8978c46 in thread0 (arg=140006953403136) at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/unix/main.c:673
#5  0x7f55e80243dc in clib_calljmp () from /lib64/libvppinfra.so.20.05.1
#6  0x7ffd742d0920 in ?? ()
#7  0x7f55e8979ced in vlib_unix_main (argc=, argv=)
at 
/usr/src/debug/vpp-20.05.1-2~gcb5420544_dirty.x86_64/src/vlib/unix/main.c:745


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18687): https://lists.fd.io/g/vpp-dev/message/18687
Mute This Topic: https://lists.fd.io/mt/80421445/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] Jenkins/Gerrit Failure Cause Notifications

[Dave Barach]

Thanks very much!

Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: Tuesday, February 2, 2021 8:28 PM
To: vpp-dev 
Subject: [vpp-dev] Jenkins/Gerrit Failure Cause Notifications

Folks,

Per a request by Dave Barach in the VPP Monthly Community Meeting, I have added 
new rules to the VPP Failure Cause Management database [0] of the Jenkins Build 
Analyzer plugin [1] to provide notifications in gerrit/jenkins of build failure 
indications.  The rules are applied to the log of each Jenkins job which fails 
to identify the failure cause in the build log.

You can preview the notifications in the gerrit change [2] which I have been 
using to verify that the rules work correctly.  You will see the description of 
the build failure cause listed on the Gerrit notification status line.  The 
jenkins job status page will contain links in the "Identified problems" section 
of the page for each rule.

Please note that in there is an issue with the reporting of multiple instances 
of same failure contained in a build log (or maybe that is a non-feature of the 
plugin).  Presently only the 1st failure is listed in the indications list on 
the jenkins build status page.  In particular, in the case of multiple 'make 
test' testcase failures [3], you will need to search the log for any additional 
failures beyond one linked to in the 'Indication 1' link [4].

I will continue to monitor job failures for viable failure signatures that I 
can add to the .  If you find a failure that you think is a good candidate, 
then please directly email me the URL to the jenkins job build status page 
along with the string to search for in the log and I will add a new rule for it.

Thanks,
-daw-

[0] https://plugins.jenkins.io/build-failure-analyzer/
[1] https://jenkins.fd.io/view/vpp/failure-cause-management/
[2] https://gerrit.fd.io/r/c/vpp/+/31092
[3] https://jenkins.fd.io/job/vpp-verify-master-ubuntu1804-x86_64/2050/
[4]
https://jenkins.fd.io/job/vpp-verify-master-ubuntu1804-x86_64/2050/consoleFull#-14603433817be1b593-44ad-45a7-8ca6-701783403621


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18649): https://lists.fd.io/g/vpp-dev/message/18649
Mute This Topic: https://lists.fd.io/mt/80343945/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 g2 plugin / standalone viewer images

[Dave Barach]

Available at https://github.com/dbarach/vpp-event-viewer.git

. Track [golang] compiler / runtime changes 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18593): https://lists.fd.io/g/vpp-dev/message/18593
Mute This Topic: https://lists.fd.io/mt/80107600/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 musl integration and CI

[Dave Barach]

Ack. 

 

Take a look at .../extras/snap/snapcraft.yaml. I haven't built the vpp snap
in a while, but this scheme (or the flatpack / appimage equivalent) finesses
the multiple libc problem. 

 

There's a 0.0% chance that /bin/date will suddenly break. Been there, done
that.

 

D. 

 

From: vpp-dev@lists.fd.io  On Behalf Of Nathan Moos
(nmoos) via lists.fd.io
Sent: Thursday, January 21, 2021 3:38 PM
To: v...@barachs.net; Benoit Ganne (bganne) ;
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp musl integration and CI

 

Hi,

 

As the person who's been submitting most of these patches recently, my
interest is not the size of the resulting VPP binary/image, but instead the
fact that the embedded systems I'm attempting to build VPP on simply do not
use glibc at all -- they use musl as the system libc. I'm much more
concerned about the complexities associated with having multiple libcs than
I am the size of the package.

 

Nathan

  _  

From: v...@barachs.net   mailto:v...@barachs.net> >
Sent: Thursday, January 21, 2021 12:11
To: Benoit Ganne (bganne) mailto:bga...@cisco.com> >;
vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> >
Cc: Nathan Moos (nmoos) mailto:nm...@cisco.com> >
Subject: RE: [vpp-dev] vpp musl integration and CI 

 

I've been down this path before. 

s/glibc/musl/ fixes one set of issues, and a small set at that. [Back in the
good old days, vpp wasn't even linked against glibc.]

Here's a quick library summary:

$ ldd /usr/bin/vpp
linux-vdso.so.1 (0x7ffef81f2000)
libvlibmemory.so.21.06 =>
/lib/x86_64-linux-gnu/libvlibmemory.so.21.06 (0x7fc41d8c4000)
libvnet.so.21.06 => /lib/x86_64-linux-gnu/libvnet.so.21.06
(0x7fc41bedd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc41bed7000)
libvlib.so.21.06 => /lib/x86_64-linux-gnu/libvlib.so.21.06
(0x7fc41bd4c000)
libsvm.so.21.06 => /lib/x86_64-linux-gnu/libsvm.so.21.06
(0x7fc41bd2e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc41bd23000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fc41bcfe000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
(0x7fc41bcf5000)
libvppinfra.so.21.06 => /lib/x86_64-linux-gnu/libvppinfra.so.21.06
(0x7fc41bc81000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc41bb32000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1
(0x7fc41ba9f000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1
(0x7fc41b7c9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc41b5d5000)
/lib64/ld-linux-x86-64.so.2 (0x7fc41d9ba000)

By the time all is said and done, there's little chance that a vpp alpine
image would be less than O(10mb).  

I'd suggest that folks investigate single-image, one-size-fits-all packaging
technology: snap, flatpak, or appimage.  

FWIW... Dave 

-Original Message-
From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Benoit Ganne
(bganne) via lists.fd.io
Sent: Thursday, January 21, 2021 2:08 PM
To: vpp-dev@lists.fd.io  
Cc: Nathan Moos (nmoos) mailto:nm...@cisco.com> >
Subject: [vpp-dev] vpp musl integration and CI

Hi everyone,

There is some on-going work to make VPP works with musl libc instead of
glibc:
https://gerrit.fd.io/r/q/topic:%22musl%22+(status:open%20OR%20status:merged)
The goal is to be able to run VPP on embedded platforms relying on musl.
The modifications are overall pretty small, but we'd like to add an
integration job using Alpine Linux which does use musl to make sure it will
not break in the future.
What do you think? Is it something that would be possible in the LF infra?

Best
ben


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18580): https://lists.fd.io/g/vpp-dev/message/18580
Mute This Topic: https://lists.fd.io/mt/80012247/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 musl integration and CI

[Dave Barach]

I've been down this path before. 

s/glibc/musl/ fixes one set of issues, and a small set at that. [Back in the
good old days, vpp wasn't even linked against glibc.]

Here's a quick library summary:

$ ldd /usr/bin/vpp
linux-vdso.so.1 (0x7ffef81f2000)
libvlibmemory.so.21.06 =>
/lib/x86_64-linux-gnu/libvlibmemory.so.21.06 (0x7fc41d8c4000)
libvnet.so.21.06 => /lib/x86_64-linux-gnu/libvnet.so.21.06
(0x7fc41bedd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc41bed7000)
libvlib.so.21.06 => /lib/x86_64-linux-gnu/libvlib.so.21.06
(0x7fc41bd4c000)
libsvm.so.21.06 => /lib/x86_64-linux-gnu/libsvm.so.21.06
(0x7fc41bd2e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc41bd23000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fc41bcfe000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
(0x7fc41bcf5000)
libvppinfra.so.21.06 => /lib/x86_64-linux-gnu/libvppinfra.so.21.06
(0x7fc41bc81000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc41bb32000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1
(0x7fc41ba9f000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1
(0x7fc41b7c9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc41b5d5000)
/lib64/ld-linux-x86-64.so.2 (0x7fc41d9ba000)

By the time all is said and done, there's little chance that a vpp alpine
image would be less than O(10mb).  

I'd suggest that folks investigate single-image, one-size-fits-all packaging
technology: snap, flatpak, or appimage.  

FWIW... Dave 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne
(bganne) via lists.fd.io
Sent: Thursday, January 21, 2021 2:08 PM
To: vpp-dev@lists.fd.io
Cc: Nathan Moos (nmoos) 
Subject: [vpp-dev] vpp musl integration and CI

Hi everyone,

There is some on-going work to make VPP works with musl libc instead of
glibc:
https://gerrit.fd.io/r/q/topic:%22musl%22+(status:open%20OR%20status:merged)
The goal is to be able to run VPP on embedded platforms relying on musl.
The modifications are overall pretty small, but we'd like to add an
integration job using Alpine Linux which does use musl to make sure it will
not break in the future.
What do you think? Is it something that would be possible in the LF infra?

Best
ben


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18576): https://lists.fd.io/g/vpp-dev/message/18576
Mute This Topic: https://lists.fd.io/mt/80012247/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 packet generator scripts

[Dave Barach]

Here are a couple of relevant configs. HTH... Dave

 

VPP UUT configuration:

 

set int ip address FortyGigabitEthernet1/0/0 192.168.40.1/24

set int ip address FortyGigabitEthernet1/0/1 192.168.41.1/24

set int state FortyGigabitEthernet1/0/0 up

set int state FortyGigabitEthernet1/0/1 up

 

ip route add 192.168.50.10/32 via 192.168.41.2

ip route add 192.168.51.10/32 via 192.168.40.2

 

VPP traffic generator:

 

set term pag off

set int ip address FortyGigabitEthernet1/0/0 192.168.40.2/24

set int ip address FortyGigabitEthernet1/0/1 192.168.41.2/24

set int state FortyGigabitEthernet1/0/0 up

set int state FortyGigabitEthernet1/0/1 up

 

comment { send traffic to the VPP UUT }

 

packet-generator new {

name worker0

worker 0

limit 0

rate 1.2e7

size 128-128

tx-interface FortyGigabitEthernet1/0/0

node FortyGigabitEthernet1/0/0-output

data { IP4: 1.2.40 -> 3cfd.fed0.b6c8

   UDP: 192.168.40.10 -> 192.168.50.10 ttl 3

   UDP: 1234 -> 2345

   incrementing 114

}

}

 

packet-generator new {

name worker1

worker 1

limit 0

rate 1.2e7

size 128-128

tx-interface FortyGigabitEthernet1/0/1

node FortyGigabitEthernet1/0/1-output

data { IP4: 1.2.4 -> 3cfd.fed0.b6c9

   UDP: 192.168.41.10 -> 192.168.51.10

   UDP: 1234 -> 2345

   incrementing 114

}

}

 

comment { delete return traffic on sight }

 

ip route add 192.168.50.0/24 via drop

ip route add 192.168.51.0/24 via drop

 

From: vpp-dev@lists.fd.io  On Behalf Of Yaser Azfar
Sent: Tuesday, January 12, 2021 4:55 PM
To: fdio+vpp-...@groups.io
Subject: [vpp-dev] vpp packet generator scripts

 

Hi team,

 

For the packet generator scripts located in src/scripts/vnet is there any 
documentation on the way these scripts are structured so that I can better 
understand the commands?

Also are there any examples of an interest packet being generated and received 
or an example of a packet being sent and received between two different 
machines?

 

I am fairly new to networking and am struggling with this so any help would be 
greatly appreciated,

Thank you


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18512): https://lists.fd.io/g/vpp-dev/message/18512
Mute This Topic: https://lists.fd.io/mt/79636283/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] latest gerrit vpp build fails?

[Dave Barach]

Try "make install-dep install-ext-deps"...

 

From: vpp-dev@lists.fd.io  On Behalf Of hemant via
lists.fd.io
Sent: Sunday, December 27, 2020 7:35 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] latest gerrit vpp build fails?

 

I used the following steps to download latest vpp:

 

git clone https://gerrit.fd.io/r/vpp

sudo make install-deps

sudo make build-release

 

The build failure log is included below.

 

Do I have to do a "git checkout xxx" version to the build to succeed and if
so, what is the version?

 

Thanks,

 

Hemant

 

[1788/2395] Building C object plugin...es/dpdk_plugin.dir/device/format.c.o

FAILED: plugins/dpdk/CMakeFiles/dpdk_plugin.dir/device/format.c.o 

ccache /usr/bin/clang-9 --target=x86_64-linux-gnu -DHAVE_MEMFD_CREATE
-Ddpdk_plugin_EXPORTS -I/home/hemant/gerr/vpp/src -I. -Iinclude
-I/home/hemant/gerr/vpp/src/plugins -Iplugins
-I/opt/vpp/external/x86_64/include -Wno-address-of-packed-member -g -fPIC
-Werror -Wall -march=corei7 -mtune=corei7-avx  -O2 -fstack-protector
-DFORTIFY_SOURCE=2 -fno-common  -fPIC   -fvisibility=hidden
-ffunction-sections -fdata-sections -MD -MT
plugins/dpdk/CMakeFiles/dpdk_plugin.dir/device/format.c.o -MF
plugins/dpdk/CMakeFiles/dpdk_plugin.dir/device/format.c.o.d -o
plugins/dpdk/CMakeFiles/dpdk_plugin.dir/device/format.c.o   -c
/home/hemant/gerr/vpp/src/plugins/dpdk/device/format.c

/home/hemant/gerr/vpp/src/plugins/dpdk/device/format.c:874:5: error: use of
undeclared identifier 'RTE_MBUF_DYNFLAG_RX_TIMESTAMP_NAME'

foreach_dpdk_pkt_dyn_rx_offload_flag

^

/home/hemant/gerr/vpp/src/plugins/dpdk/device/format.c:113:3: note: expanded
from macro 'foreach_dpdk_pkt_dyn_rx_offload_flag'

  _ (RX_TIMESTAMP, 0, "Timestamp field is valid")

  ^

/home/hemant/gerr/vpp/src/plugins/dpdk/device/format.c:862:49: note:
expanded from macro '_'

rx_dynflag_offset = rte_mbuf_dynflag_lookup(RTE_MBUF_DYNFLAG_##F##_NAME,
\

^

:14:1: note: expanded from here

RTE_MBUF_DYNFLAG_RX_TIMESTAMP_NAME

^

1 error generated.

[1795/2395] Building C object vnet/C...s/vnet.dir/devices/virtio/device.c.o

ninja: build stopped: subcommand failed.

Makefile:693: recipe for target 'vpp-build' failed

make[1]: *** [vpp-build] Error 1

make[1]: Leaving directory '/home/hemant/gerr/vpp/build-root'

Makefile:365: recipe for target 'build-release' failed

make: *** [build-release] Error 2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18436): https://lists.fd.io/g/vpp-dev/message/18436
Mute This Topic: https://lists.fd.io/mt/79260685/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] Core Load Calculation

[Dave Barach]

As the sole remaining original vpp author and the area maintainer, I have 
abundant experience dealing with src/vlib/{main.c, threads.c}.

In every case to date, we’ve been able to leverage existing callback hooks, or 
to add callback hooks so that folks can do what they need to do (e.g. from 
plugins) without modifying the core engine.

Might we manage to take that approach here? It’s in everyone’s interest to do 
so...

Thanks... Dave

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18393): https://lists.fd.io/g/vpp-dev/message/18393
Mute This Topic: https://lists.fd.io/mt/78980301/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] move to clang-format

[Dave Barach]

+1. Wholesale reformatting of existing files is to be avoided. 

 

Support for per-file or per-directory automated code formatting would be great! 

 

Religious debates about coding style will be resolved one day after there’s 
peace in Palestine. Let’s not go there. OK?

 

Thanks... Dave

 

 

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Thursday, December 17, 2020 1:29 PM
To: Jon Loeliger via lists.fd.io 
Cc: vpp-dev 
Subject: Re: [vpp-dev] move to clang-format

 

 


On 17.12.2020., at 19:06, Jon Loeliger via lists.fd.io 
mailto:jdl=netgate@lists.fd.io> > wrote:



 

 

On Sun, Dec 13, 2020 at 6:15 AM Damjan Marion via lists.fd.io 
  mailto:me@lists.fd.io> > 
wrote:


Hi,

I was playing a bit with clang-format as replacement to gnu indent which we use 
today[1].

While it is impossible to render exact same result like gnu indent, good thing 
is that clang-format can be used only on lines which are changed in the diff so 
no major reformat is needed. My patch deos exactly that.

 

I would welcome any change away from the absolutely horrendous Gnu coding style!

 

 

And what would be good alternative in your view?

 

I doubt we want to reformat whole codebase, eventually allow alternative for 
new files in the repo...

 

— 

Damjan

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18392): https://lists.fd.io/g/vpp-dev/message/18392
Mute This Topic: https://lists.fd.io/mt/78925374/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] Message posting policy change

[Dave Barach]

OK… Done deal... Thanks... Dave

> On Dec 16, 2020, at 11:31 AM, Florin Coras  wrote:
> 
> +1
> 
> Florin
> 
>> On Dec 16, 2020, at 4:47 AM, Dave Barach  wrote:
>> 
>> Folks,
>>
>> At the moment, we hold non-list-member posts in the vpp-dev moderation 
>> queue. Unfortunately, spam comprises almost all of the messages in the 
>> queue. I’ve been deleting 10-20 junk emails per day – “want to buy a list of 
>> conference attendees?” - and I would like to spend that time doing something 
>> else.
>>
>> Any objections to reconfiguring the vpp-dev@lists.fd.io group to reject 
>> messages from non-list-members? For those who participate sporadically, it’s 
>> easy to turn on/off message delivery. For regular list participants, nothing 
>> changes.
>>
>> Thanks... Dave
>> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18374): https://lists.fd.io/g/vpp-dev/message/18374
Mute This Topic: https://lists.fd.io/mt/78999410/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] move to clang-format

[Dave Barach]

Seems like a good time to flip the switch... Thanks... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Wednesday, December 16, 2020 9:12 AM
To: vpp-dev 
Subject: Re: [vpp-dev] move to clang-format


Any feedback?

Any good reason not to do the switch now when we have stable/2101 created?

Thanks,

Damjan


> On 14.12.2020., at 09:32, Benoit Ganne (bganne)  wrote:
> 
> Sounds good to me, clang-format should be more consistent than indent...
> 
> ben
> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  On Behalf Of Damjan 
>> Marion via lists.fd.io
>> Sent: dimanche 13 décembre 2020 13:16
>> To: vpp-dev 
>> Subject: [vpp-dev] move to clang-format
>> 
>> 
>> Hi,
>> 
>> I was playing a bit with clang-format as replacement to gnu indent 
>> which we use today[1].
>> 
>> While it is impossible to render exact same result like gnu indent, 
>> good thing is that clang-format can be used only on lines which are 
>> changed in the diff so no major reformat is needed. My patch deos exactly 
>> that.
>> 
>> Another good thing is that clang-format can learn about custom 
>> foreach macros se we can significantly reduce amount of 
>> INDENT-OFF/INDENT-ON sections in the code. It also properly formats 
>> registration macros like
>> VLIB_REGISTER_NODE() which again means less INDENT-OFF/INDENT-ON.
>> 
>> What it cannot deal with is macros which include body of function as 
>> argument. Three most popular ones are pool_foreach, 
>> pool_foreach_index and clib_bitmap_foreach. To address this I created 
>> patch[2] which adds simpler variant of the macros. Instead of writing
>> 
>> pool_foreach (e, pool ({
>>  /* some code */
>> }));
>> 
>> New macro looks like:
>> 
>> pool_foreach2 (e, pool)
>>  /* some code */
>> 
>> Here we have option to either maintain both macros, or do one-shot 
>> replacement.
>> 
>> As we plan to move to ubuntu 20.04 post 21.01 release, and that comes 
>> with lot of gnu indent pain, it might be also good time to move to 
>> clang- format. It is obvious that gnu indent is on the sunset of it’s 
>> existence and no new development happening for years.
>> 
>> Thoughts?
>> 
>> —
>> Damjan
>> 
>> [1] https://gerrit.fd.io/r/c/vpp/+/30395
>> [2] https://gerrit.fd.io/r/c/vpp/+/30393
>> 
>> 
>> 
>> 
>> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18358): https://lists.fd.io/g/vpp-dev/message/18358
Mute This Topic: https://lists.fd.io/mt/78925374/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Message posting policy change

[Dave Barach]

Folks,

 

At the moment, we hold non-list-member posts in the vpp-dev moderation
queue. Unfortunately, spam comprises almost all of the messages in the
queue. I've been deleting 10-20 junk emails per day - "want to buy a list of
conference attendees?" - and I would like to spend that time doing something
else.

 

Any objections to reconfiguring the vpp-dev@lists.fd.io
  group to reject messages from
non-list-members? For those who participate sporadically, it's easy to turn
on/off message delivery. For regular list participants, nothing changes.

 

Thanks... Dave


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18353): https://lists.fd.io/g/vpp-dev/message/18353
Mute This Topic: https://lists.fd.io/mt/78999410/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] Core Load Calculation

[Dave Barach]

In rough terms, you can model vector size as a function of offered load [and 
graph trajectory / configured features] with three linear segments. 

 

*   Dead asleep – single-digit vector sizes
*   Keeping up – vector sizes up to the no-drop offered load
*   Hitting the wall – vector sizes from the keep-up max to 256

 

Each of the three segments has a different slope. 

 

You might: find the true no-drop rate vector size. Call that point 100%. Find 
the inflection point at the end of the “dead asleep” region. Call that point 
5%. Compute the slope of the “keeping up” region, verify with multiple 
measurements. 

 

At that point, you can construct a function (or lookup table) tuned for your 
specific application.

 

Of course, you can map vector sizes to reported load however you like. 

 

HTH... Dave

 

P.S. Beware of creating an FAA-approved (aircraft) fuel gauge, which makes one 
promise: when the tanks are empty, the gauge will read empty.

 

From: vpp-dev@lists.fd.io  On Behalf Of Ramkumar B
Sent: Tuesday, December 15, 2020 11:53 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Core Load Calculation

 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards,

Ramkumar Balu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18345): https://lists.fd.io/g/vpp-dev/message/18345
Mute This Topic: https://lists.fd.io/mt/78980301/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] move to clang-format

[Dave Barach]

Let me help with a sales pitch for pool_foreach2(): in this form one can set 
gdb breakpoints in the loop body. All by itself, that's a good enough reason to 
switch...

Thanks for this one!

Dave


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Sunday, December 13, 2020 7:16 AM
To: vpp-dev 
Subject: [vpp-dev] move to clang-format


Hi,

I was playing a bit with clang-format as replacement to gnu indent which we use 
today[1].

While it is impossible to render exact same result like gnu indent, good thing 
is that clang-format can be used only on lines which are changed in the diff so 
no major reformat is needed. My patch deos exactly that.

Another good thing is that clang-format can learn about custom foreach macros 
se we can significantly reduce amount of INDENT-OFF/INDENT-ON sections in the 
code. It also properly formats registration macros like VLIB_REGISTER_NODE() 
which again means less INDENT-OFF/INDENT-ON.

What it cannot deal with is macros which include body of function as argument. 
Three most popular ones are pool_foreach, pool_foreach_index and 
clib_bitmap_foreach. To address this I created patch[2] which adds simpler 
variant of the macros. Instead of writing 

pool_foreach (e, pool ({
  /* some code */
}));

New macro looks like:

pool_foreach2 (e, pool)
  /* some code */

Here we have option to either maintain both macros, or do one-shot replacement.

As we plan to move to ubuntu 20.04 post 21.01 release, and that comes with lot 
of gnu indent pain, it might be also good time to move to clang-format. It is 
obvious that gnu indent is on the sunset of it’s existence and no new 
development happening for years.

Thoughts?

— 
Damjan

[1] https://gerrit.fd.io/r/c/vpp/+/30395
[2] https://gerrit.fd.io/r/c/vpp/+/30393



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18321): https://lists.fd.io/g/vpp-dev/message/18321
Mute This Topic: https://lists.fd.io/mt/78925374/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] New perfmon plugin

[Dave Barach]

Looks really cool! Feel free to move the old one to deprecated... ... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Friday, December 11, 2020 11:14 AM
To: vpp-dev 
Subject: [vpp-dev] New perfmon plugin


Guys,

I just submitted patch with the new perfmon plugin: [1]

It takes significantly different approach compared to current one.

 - it support multiple sources of perf counters (linux, intel core, intel 
uncore) and it is extensible to other vendors
 - it have concept instances so it can monitor multiple instances of specific 
PMU (DRAM channels, UPI/QPU links, ..)
 - it supports node, thread and system metrics
 - different metrics are organized in bundles, where bundle consists of 
multiple counters and format functions which calculates and presents metric. 
Yuo can find example of bundle here [2]

To se how this looks in action, I captured small asciinema video: [3]

As this new plugin is significantly different than old one, I wonder if anyone 
thinks we should keep old une.
Also, any other feedback is wellcome.

Thanks,

Damjan


[1] https://gerrit.fd.io/r/c/vpp/+/30186
[2] 
https://gerrit.fd.io/r/c/vpp/+/30186/12/src/plugins/perfmon/intel/bundle/load_blocks.c
[3] https://asciinema.org/a/aFN5rMFYw0RPvGOZiFsziXV5w



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18310): https://lists.fd.io/g/vpp-dev/message/18310
Mute This Topic: https://lists.fd.io/mt/78882331/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 g2 live viewer plugin / standalone image available

[Dave Barach]

At https://github.com/dbarach/vpp-event-viewer 

 

Changes since last code drop:

Improve README.md, best viewed directly on github.com

Fix summary-mode toggle

Fix dialog "OK" button behavior.

Clean up shift-mouse and control-mouse handling a bit

Add mouse gestures to the About->Keyboard Shortcuts menu

Use radio button menu to select track move destination

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18308): https://lists.fd.io/g/vpp-dev/message/18308
Mute This Topic: https://lists.fd.io/mt/78856088/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] don't see any interface but local0

[Dave Barach]

Most likely, the corresponding Linux interface is up. Try running vpp
manually from the command-line, and look for messages of this form:

 

vlib_pci_bind_to_uio: Skipping PCI device :00:1f.6 as host interface
eno2 is up

vlib_pci_bind_to_uio: Skipping PCI device :02:00.0 as host interface
enp2s0f0 is up

vlib_pci_bind_to_uio: Skipping PCI device :02:00.1 as host interface
enp2s0f1 is up

vlib_pci_bind_to_uio: Skipping PCI device :03:00.0 as host interface
enp3s0f0 is up

 

We should change pci.c to put these messages in the vlib log. 

 

D.

 

P.S. "# /build-root/install-vpp-native/vpp/bin/vpp unix interactive"

 

From: vpp-dev@lists.fd.io  On Behalf Of hemant via
lists.fd.io
Sent: Saturday, December 5, 2020 9:21 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] don't see any interface but local0

 

I am using latest VPP on Ubuntu 18.04. I have at least eth0-eth3 interfaces
on my machine.

 

This is a log for what I did and do not see any interface but local0 in the
output of "show interface"?

 

hemant@upper:~/vpp$ sudo make run-release

[sudo] password for hemant: 

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 } dpdk { no-pci } 

 

dpdk [warn  ]: not enough DPDK crypto resources

dpdk/cryptodev   [warn  ]: dpdk_cryptodev_init: Not enough cryptodevs

vat-plug/load[error ]:
/home/hemant/vpp/build-root/install-vpp-native/vpp/lib/vpp_api_test_plugins/
upf_test_plugin.so: undefined symbol: upf_main

vat-plug/load[error ]: vat_plugin_register: oddbuf plugin not loaded...

_____   _  ___ 

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

_/ _// // / / / _ \   | |/ / ___/ ___/

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

 

vpp# sh interface 

  Name   IdxState  MTU (L3/IP4/IP6/MPLS)
Counter  Count 

local00 down  0/0/0/0   

vpp#

 

I did search for the issue first and found:

 

https://www.mail-archive.com/vpp-dev@lists.fd.io/msg00609.html

 

But the above link does not clue me in.

 

Thanks,

 

Hemant

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18255): https://lists.fd.io/g/vpp-dev/message/18255
Mute This Topic: https://lists.fd.io/mt/78747831/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]: Worker Thread Deadlock Detected from vl_api_clnt_node

[Dave Barach]

Looks like a corrupt binary API segment heap to me. Signal 7 in 
mspace_malloc(...) is the root cause. The thread hangs due to recursion on the 
mspace lock trying to print / syslog from the signal handler.  

 

It is abnormal to allocate memory in vl_msg_api_alloc[_as_if_client] in the 
first place. 

 

As has been communicated multiple times, 19.08 is no longer supported. 

 

HTH... Dave

 

#13 0x7ffa9f72adf5 in unix_signal_handler (signum=7, si=0x7ffa6f6e50f0, 
uc=0x7ffa6f6e4fc0)
at /development/libvpp/src/vlib/unix/main.c:127
#14 
#15 0x7ffa9f417c03 in mspace_malloc (msp=0x130046010, bytes=77) at 
/development/libvpp/src/vppinfra/dlmalloc.c:4437
#16 0x7ffa9f416f6f in mspace_get_aligned (msp=0x130046010, 
n_user_data_bytes=77, align=1, align_offset=0)
at /development/libvpp/src/vppinfra/dlmalloc.c:4186
#17 0x7ffaa0c7d04f in clib_mem_alloc_aligned_at_offset (size=73, align=1, 
align_offset=0, os_out_of_memory_on_failure=1)
at /development/libvpp/src/vppinfra/mem.h:139
#18 0x7ffaa0c7d0a2 in clib_mem_alloc (size=73) at 
/development/libvpp/src/vppinfra/mem.h:155
#19 0x7ffaa0c7da0a in vl_msg_api_alloc_internal (nbytes=73, pool=0, 
may_return_null=0)
at /development/libvpp/src/vlibmemory/memory_shared.c:177
#20 0x7ffaa0c7db6f in vl_msg_api_alloc_as_if_client (nbytes=57) at 
/development/libvpp/src/vlibmemory/memory_shared.c:236



 

From: vpp-dev@lists.fd.io  On Behalf Of Rajith PR via 
lists.fd.io
Sent: Thursday, December 3, 2020 5:55 AM
To: vpp-dev 
Subject: [vpp-dev]: Worker Thread Deadlock Detected from vl_api_clnt_node

 

Hi All,

 

We have hit a VPP Worker Thread Deadlock issue. And from the call stacks it 
looks like the main thread is waiting for workers to come back to their main 
loop( ie has taken the barrier lock) and one of the two workers is on spin lock 
to make an rpc to the main thread. 

I believe this lock is held by the main thread. 

 

We are using 19.08 version and complete bt is pasted below. Also, Can someone 
explain the purpose of vl_api_clnt_node.

  
414 /* *INDENT-OFF* */
  
415 VLIB_REGISTER_NODE 
  
(vl_api_clnt_node 
 ) =
  
416 {
  
417   .function   = 
vl_api_clnt_process 
 ,
  
418   .type   = 
VLIB_NODE_TYPE_PROCESS,
  
419   .name   = 
"api-rx-from-ring",
  
420   .state   = 
VLIB_NODE_STATE_DISABLED,
  
421 };
  
422 /* *INDENT-ON* */
Complete Backtrace:
Thread 3 (Thread 0x7ffa511c9700 (LWP 448)):
---Type  to continue, or q  to quit---
#0  0x7ffa9f6bc276 in vlib_worker_thread_barrier_check () at 
/development/libvpp/src/vlib/threads.h:430
#1  0x7ffa9f6c3f19 in vlib_main_or_worker_loop (vm=0x7ffa8797adc0, 
is_main=0) at /development/libvpp/src/vlib/main.c:1757
#2  0x7ffa9f6c4fbd in vlib_worker_loop (vm=0x7ffa8797adc0) at 
/development/libvpp/src/vlib/main.c:1988
#3  0x7ffa9f703ff1 in vlib_worker_thread_fn (arg=0x7ffa6ccc8640) at 
/development/libvpp/src/vlib/threads.c:1803
#4  0x7ffa9f383560 in clib_calljmp () from 
/usr/local/lib/libvppinfra.so.1.0.1
#5  0x7ffa511c8ec0 in ?? ()
#6  0x7ffa9f6fe588 in vlib_worker_thread_bootstrap_fn (arg=0x7ffa6ccc8640) 
at /development/libvpp/src/vlib/threads.c:573
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0x7ffa519ca700 (LWP 447)):
#0  0x7ffaaae87ef7 in sched_yield () at 
../sysdeps/unix/syscall-template.S:78
#1  0x7ffa9f40fb49 in spin_acquire_lock (sl=0x130046384) at 
/development/libvpp/src/vppinfra/dlmalloc.c:466
#2  0x7ffa9f4173a4 in mspace_malloc (msp=0x130046010, bytes=66) at 
/development/libvpp/src/vppinfra/dlmalloc.c:4347
#3  0x7ffa9f4170de in mspace_get_aligned (msp=0x130046010, 
n_user_data_bytes=66, align=16, align_offset=8)
at /development/libvpp/src/vppinfra/dlmalloc.c:4233
#4  0x7ffa9f4036fc in clib_mem_alloc_aligned_at_offset (size=46, align=8, 
align_offset=8, os_out_of_memory_on_failure=1)
at 

Re: [vpp-dev] support of multiple startup-config files in startup.conf

[Dave Barach]

If you want a one-minute manager solution, use the “exec” command in 
/etc/vpp/vpp-startup.conf to source as many files as you like. 

 

Here’s one way to exploit that scheme:

 

define HOSTNAME myvppgateway

define TRUNK GigabitEthernet3/0/0

 

comment { inside subnet 192.168..0/24 }

define INSIDE_SUBNET 2

 

define INSIDE_PORT1 GigabitEthernet6/0/0

define INSIDE_PORT2 GigabitEthernet6/0/1

define INSIDE_PORT3 GigabitEthernet8/0/0

define INSIDE_PORT4 GigabitEthernet8/0/1

 

comment { feature selections }

define FEATURE_NAT44 comment

define FEATURE_CNAT uncomment

define FEATURE_DNS comment

define FEATURE_IP6 comment

define FEATURE_IKE_RESPONDER comment

define FEATURE_MACTIME uncomment

 

exec /etc/vpp/setup.tmpl

 

where setup.tmpl might use the macro definitions like so:

 

$(FEATURE_NAT44) { $(FEATURE_IKE_RESPONDER) { nat44 add identity mapping 
external $(TRUNK) udp 500 } }

$(FEATURE_NAT44) { $(FEATURE_IKE_RESPONDER) { nat44 add identity mapping 
external $(TRUNK) udp 4500 } }

 

 

D.

 

From: vpp-dev@lists.fd.io  On Behalf Of 
ashish.sax...@hsc.com
Sent: Sunday, November 29, 2020 11:05 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] support of multiple startup-config files in startup.conf

 

Hi All,

To read startup operational configuration of vpp from a file, we modify the 
/etc/vpp/startup.conf file as:

unix {

  nodaemon

  log /var/log/vpp/vpp.log

  full-coredump

  cli-listen /run/vpp/cli.sock

  startup-config /etc/vpp/vpp-startup.config

  gid vpp

}

Can we provide 2 filenames here instead of one so that 2 startup-config files 
will get create.

Thanks ,
Ashish 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18201): https://lists.fd.io/g/vpp-dev/message/18201
Mute This Topic: https://lists.fd.io/mt/78601194/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] unformat fails processing > 3 variables

[Dave Barach]

This will make you sad. Don’t write code line this:

 

 if (unformat (line_input, "%s %s %x %hhu %hhu %hu %hu %s %hhu %hu %hu %u 
%x %x %hu %hhu %hhu", ...))

 

 

If you want to parse a bunch of different fields, do it this way, aka the way 
it’s done elsewhere in the code base:

 

if (unformat (line_input, “table-name %s”, _name))

;

else if (unformat (line_input, “action-name %s”, _name)

;

... etc ...

} else {

 error = clib_error_return

}

 

That way you can provide default values – and an accurate help string! – which 
might help you type what you mean. Steven already found one typo. There are 
probably several more.

 

From: vpp-dev@lists.fd.io  On Behalf Of hemant via 
lists.fd.io
Sent: Friday, November 27, 2020 7:24 PM
To: slu...@cisco.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] unformat fails processing > 3 variables

 

Sorry, I fat-fingered one format tag during moving the snippet of code to 
github.  Even with 18 format tags and 18 args, I still fail.  I used a 
delimiter of “=>” between table entry key and the entry value.

 

vpp# upf add-entry pkt_filter4_0 permit4 0xac100102 0xac100202 17 0 61 2152 => 
130 0 1 5241 0x03030302 0x03030301 2152 1 0

upf add-entry: unknown input ''

vpp#

 

Thanks,

 

Hemant

 

From: Steven Luong (sluong) mailto:slu...@cisco.com> > 
Sent: Friday, November 27, 2020 7:14 PM
To: hem...@mnkcg.com  ; vpp-dev@lists.fd.io 
 
Subject: Re: [vpp-dev] unformat fails processing > 3 variables

 

You have 17 format tags, but you pass 18 arguments to the unformat function. Is 
that intentional?

 

Steven

 

From: mailto:vpp-dev@lists.fd.io> > on behalf of "hemant 
via lists.fd.io" mailto:hemant=mnkcg@lists.fd.io> >
Reply-To: "hem...@mnkcg.com  " mailto:hem...@mnkcg.com> >
Date: Friday, November 27, 2020 at 3:52 PM
To: "vpp-dev@lists.fd.io  " mailto:vpp-dev@lists.fd.io> >
Subject: [vpp-dev] unformat fails processing > 3 variables

 

I am writing VPP CLI for the first time. Please see this new CLI I developed 
for my VPP plugin at the link below.

 

https://github.com/hesingh/misc/blob/master/vpp-issues/cli.c

 

If I use more than three variables with unformat on line 
, I run into 
the error on this line of code in the same file 


 

Any idea how to get around this issue?

 

Thanks,

 

Hemant

 

 

 

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18181): https://lists.fd.io/g/vpp-dev/message/18181
Mute This Topic: https://lists.fd.io/mt/78558564/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-