[vpp-dev] Unable to ping vpp interface from outside after configuring vrrp on vpp interface and making it as Master

[Amit Mehra]

Hi,

I am trying to test VRRP functionality using VRRP plugin available in VPP-20.05 
and after running VRRP functionality on one of the VPP nodes and configuring it 
as a master, i am not able to ping the vpp interface from outside. I am using 
the following configuration

modprobe -r vfio_pci
modprobe -r vfio

./bin/dpdk-devbind.py -s                  // bind to vfio-pci driver

Network devices using DPDK-compatible driver

:13:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
:1b:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3

./bin/vppctl create interface vmxnet3 :13:00.0
./bin/vppctl set interface ip address vmxnet3-0/13/0/0 10.20.53.143/24
./bin/vppctl set int state vmxnet3-0/13/0/0 up

./bin/vppctl vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255 interval 1 
accept_mode 10.20.53.143
./bin/vppctl vrrp proto start GigabitEthernet13/0/0 vr_id 1

Also, when i am trying to ping this vpp interface ip(10.20.53.143) from outside 
machine(which is having same subnet as 10.20.53.xx), I could see that ARP 
request was received by vpp and responded with a MAC address as 
00:00:5E:00:01:01 in ARP Reply.
However, the icmp packets were not entering the vpp. Verified the same using 
"trace" functionality available in vpp i.e. trace add vmxnet3-input 200

Moreover, i could see that vrrp packets(Announcement) continuously being 
transmitted by the vpp interface.

Can someone confirm whether i am following correct steps and what could be the 
reason why icmp packets are not being received by vpp? I tried by enabling 
promiscuous mode on vpp interface using "set interface promiscuous on 
vmxnet3-0/13/0/0" but still icmp packets were not entering the vpp.

Also, is there any CLI by which i can see that virtual MAC has been assigned on 
the vpp interface?

I also tried testing with dpdk plugin, but observing the following log in 
vpp.log while executing ./bin/vppctl vrrp proto start GigabitEthernet13/0/0 
vr_id 1 CLI

Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: vrrp_vr_transition_vmac:120: 
Adding virtual MAC address 00:00:5e:00:01:01 on hardware interface 1
Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: dpdk_add_del_mac_address: mac 
address add/del failed: -95
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] vlib_add_trace(...) - stop inlining?

[Dave Barach via lists.fd.io]

Folks,

It looks to me like inlining vlib_add_trace(...) is probably a mistake in terms 
of code bloat. Does anyone hate the idea of changing it to a standard function?

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

View/Reply Online (#16686): https://lists.fd.io/g/vpp-dev/message/16686
Mute This Topic: https://lists.fd.io/mt/74752449/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_add_trace(...) - stop inlining?

[Dave Barach via lists.fd.io]

See https://gerrit.fd.io/r/c/vpp/+/27467.

Here's the commit message:

vlib: stop inlining vlib_add_trace(...)

Packet tracing performance doesn't justify inlining vlib_add_trace(...) over 
500 times.

It makes a 15% text-segment size difference in a representative use-case:

Inline:
$ size .../vnet_skx.dir/ipsec/ipsec_input.c.o
   textdata bss dec hex filename
   6831  80   069111aff .../vnet_skx.dir/ipsec/ipsec_input.c.o

Not inline:
$ size .../vnet_skx.dir/ipsec/ipsec_input.c.o
   textdata bss dec hex filename
   5776  80   0585616e0 .../vnet_skx.dir/ipsec/ipsec_input.c.o

Retain the original code as vlib_add_trace_inline, instantiate once as 
vlib_add_trace.

Type: refactor
Signed-off-by: Dave Barach
Change-Id: Iaf431dbf00c4aad03663d86f9dd1322e84d03962

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Monday, June 8, 2020 10:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_add_trace(...) - stop inlining?

Folks,

It looks to me like inlining vlib_add_trace(...) is probably a mistake in terms 
of code bloat. Does anyone hate the idea of changing it to a standard function?

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

View/Reply Online (#16688): https://lists.fd.io/g/vpp-dev/message/16688
Mute This Topic: https://lists.fd.io/mt/74752449/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_add_trace(...) - stop inlining?

[John Lo (loj) via lists.fd.io]

Make sense to me, as saving trace data is already impacting "normal" 
performance. The extra function call is probably not much more overhead.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Monday, June 08, 2020 10:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_add_trace(...) - stop inlining?

Folks,

It looks to me like inlining vlib_add_trace(...) is probably a mistake in terms 
of code bloat. Does anyone hate the idea of changing it to a standard function?

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

View/Reply Online (#16689): https://lists.fd.io/g/vpp-dev/message/16689
Mute This Topic: https://lists.fd.io/mt/74752449/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_add_trace(...) - stop inlining?

[Damjan Marion via lists.fd.io]

Good idea, I already pressed the button…

— 
Damjan

> On 8 Jun 2020, at 17:35, Dave Barach via lists.fd.io 
>  wrote:
> 
> See https://gerrit.fd.io/r/c/vpp/+/27467 
> . 
>
> Here’s the commit message:
>
> vlib: stop inlining vlib_add_trace(...)
>
> Packet tracing performance doesn't justify inlining vlib_add_trace(...) over 
> 500 times.
>
> It makes a 15% text-segment size difference in a representative use-case:
>
> Inline:
> $ size .../vnet_skx.dir/ipsec/ipsec_input.c.o
>textdata bss dec hex filename
>6831  80   069111aff .../vnet_skx.dir/ipsec/ipsec_input.c.o
>
> Not inline:
> $ size .../vnet_skx.dir/ipsec/ipsec_input.c.o
>textdata bss dec hex filename
>5776  80   0585616e0 .../vnet_skx.dir/ipsec/ipsec_input.c.o
>
> Retain the original code as vlib_add_trace_inline, instantiate once as 
> vlib_add_trace.
>
> Type: refactor
> Signed-off-by: Dave Barach
> Change-Id: Iaf431dbf00c4aad03663d86f9dd1322e84d03962
>
> From: vpp-dev@lists.fd.io   > On Behalf Of Dave Barach via lists.fd.io 
> 
> Sent: Monday, June 8, 2020 10:13 AM
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] vlib_add_trace(...) - stop inlining?
>
> Folks,
>
> It looks to me like inlining vlib_add_trace(...) is probably a mistake in 
> terms of code bloat. Does anyone hate the idea of changing it to a standard 
> function?
>
> Thanks... Dave
> 

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

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

Re: [vpp-dev] Unable to ping vpp interface from outside after configuring vrrp on vpp interface and making it as Master

[steven luong via lists.fd.io]

Vmxnet3 is a paravirtualized device. I could be wrong, it does not appear it 
supports adding virtual mac address. This error returns from dpdk indicates 
just that.

Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: vrrp_vr_transition_vmac:120: 
Adding virtual MAC address 00:00:5e:00:01:01 on hardware interface 1
Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: dpdk_add_del_mac_address: mac 
address add/del failed: -95

#define EOPNOTSUPP  95  /* Operation not supported on transport 
endpoint */

I suggest you try it on the physical NIC to see if that works.

Steven

From:  on behalf of Amit Mehra 
Date: Monday, June 8, 2020 at 5:57 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Unable to ping vpp interface from outside after configuring 
vrrp on vpp interface and making it as Master

Hi,

I am trying to test VRRP functionality using VRRP plugin available in VPP-20.05 
and after running VRRP functionality on one of the VPP nodes and configuring it 
as a master, i am not able to ping the vpp interface from outside. I am using 
the following configuration

modprobe -r vfio_pci
modprobe -r vfio

./bin/dpdk-devbind.py -s  // bind to vfio-pci driver

Network devices using DPDK-compatible driver

:13:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
:1b:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3

./bin/vppctl create interface vmxnet3 :13:00.0
./bin/vppctl set interface ip address vmxnet3-0/13/0/0 10.20.53.143/24
./bin/vppctl set int state vmxnet3-0/13/0/0 up

./bin/vppctl vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255 interval 1 
accept_mode 10.20.53.143
./bin/vppctl vrrp proto start GigabitEthernet13/0/0 vr_id 1

Also, when i am trying to ping this vpp interface ip(10.20.53.143) from outside 
machine(which is having same subnet as 10.20.53.xx), I could see that ARP 
request was received by vpp and responded with a MAC address as 
00:00:5E:00:01:01 in ARP Reply.
However, the icmp packets were not entering the vpp. Verified the same using 
"trace" functionality available in vpp i.e. trace add vmxnet3-input 200

Moreover, i could see that vrrp packets(Announcement) continuously being 
transmitted by the vpp interface.

Can someone confirm whether i am following correct steps and what could be the 
reason why icmp packets are not being received by vpp? I tried by enabling 
promiscuous mode on vpp interface using "set interface promiscuous on 
vmxnet3-0/13/0/0" but still icmp packets were not entering the vpp.

Also, is there any CLI by which i can see that virtual MAC has been assigned on 
the vpp interface?

I also tried testing with dpdk plugin, but observing the following log in 
vpp.log while executing ./bin/vppctl vrrp proto start GigabitEthernet13/0/0 
vr_id 1 CLI

Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: vrrp_vr_transition_vmac:120: 
Adding virtual MAC address 00:00:5e:00:01:01 on hardware interface 1
Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]: dpdk_add_del_mac_address: mac 
address add/del failed: -95
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16691): https://lists.fd.io/g/vpp-dev/message/16691
Mute This Topic: https://lists.fd.io/mt/74750885/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] Best way to punt packets to the control plane

[ravi . vpp2020]

I am also searching best way to receive the packets from Device_Input node? I 
want to receive raw packets to my application. how can I achieve that? is there 
any way to receive complete L2 Packet receive at application? When I check the 
documentation I can find few ways to communicate the application with VPP but 
is there any way to communicate directly with any particular node?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Unable to ping vpp interface from outside after configuring vrrp on vpp interface and making it as Master

[Matthew Smith via lists.fd.io]

That appears to be correct. The vmxnet3 DPDK PMD looks like it does not
support adding or deleting a MAC address. I never attempted to add support
for secondary MAC addresses to the native VPP vxmnet3 driver either. So
VRRP is not able to manage secondary MAC addresses on vmxnet3 devices.

Adding a VRRP virtual MAC address to a device as a secondary MAC address is
primarily intended to avoid putting the device in promiscuous mode. Since
the vmxnet3 DPDK does not support secondary MAC addresses, you can try
setting the device in promiscuous mode. I haven't tested that in a while,
but it worked the last time I tried it.

-Matt



On Mon, Jun 8, 2020 at 11:36 AM steven luong via lists.fd.io  wrote:

> Vmxnet3 is a paravirtualized device. I could be wrong, it does not appear
> it supports adding virtual mac address. This error returns from dpdk
> indicates just that.
>
>
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> vrrp_vr_transition_vmac:120: Adding virtual MAC address 00:00:5e:00:01:01
> on hardware interface 1
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> dpdk_add_del_mac_address: mac address add/del failed: -95
>
>
>
> #define EOPNOTSUPP  95  /* Operation not supported on transport
> endpoint */
>
>
>
> I suggest you try it on the physical NIC to see if that works.
>
>
>
> Steven
>
>
>
> *From: * on behalf of Amit Mehra 
> *Date: *Monday, June 8, 2020 at 5:57 AM
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] Unable to ping vpp interface from outside after
> configuring vrrp on vpp interface and making it as Master
>
>
>
> Hi,
>
>
>
> I am trying to test VRRP functionality using VRRP plugin available in
> VPP-20.05 and after running VRRP functionality on one of the VPP nodes and
> configuring it as a master, i am not able to ping the vpp interface from
> outside. I am using the following configuration
>
>
>
> modprobe -r vfio_pci
>
> modprobe -r vfio
>
>
>
> ./bin/dpdk-devbind.py -s  // bind to vfio-pci driver
>
>
>
> Network devices using DPDK-compatible driver
>
> 
>
> :13:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
>
> :1b:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
>
>
>
> ./bin/vppctl create interface vmxnet3 :13:00.0
>
> ./bin/vppctl set interface ip address vmxnet3-0/13/0/0 10.20.53.143/24
>
> ./bin/vppctl set int state vmxnet3-0/13/0/0 up
>
>
>
> ./bin/vppctl vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255
> interval 1 accept_mode 10.20.53.143
>
> ./bin/vppctl vrrp proto start GigabitEthernet13/0/0 vr_id 1
>
>
>
> Also, when i am trying to ping this vpp interface ip(10.20.53.143) from
> outside machine(which is having same subnet as 10.20.53.xx), I could see
> that ARP request was received by vpp and responded with a MAC address as
> 00:00:5E:00:01:01 in ARP Reply.
>
> However, the icmp packets were not entering the vpp. Verified the same
> using "trace" functionality available in vpp i.e. trace add vmxnet3-input
> 200
>
>
>
> Moreover, i could see that vrrp packets(Announcement) continuously being
> transmitted by the vpp interface.
>
>
>
> Can someone confirm whether i am following correct steps and what could be
> the reason why icmp packets are not being received by vpp? I tried by
> enabling promiscuous mode on vpp interface using "set interface promiscuous
> on vmxnet3-0/13/0/0" but still icmp packets were not entering the vpp.
>
> Also, is there any CLI by which i can see that virtual MAC has been
> assigned on the vpp interface?
>
>
>
> I also tried testing with dpdk plugin, but observing the following log in
> vpp.log while executing ./bin/vppctl vrrp proto start GigabitEthernet13/0/0
> vr_id 1 CLI
>
>
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> vrrp_vr_transition_vmac:120: Adding virtual MAC address 00:00:5e:00:01:01
> on hardware interface 1
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> dpdk_add_del_mac_address: mac address add/del failed: -95
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16693): https://lists.fd.io/g/vpp-dev/message/16693
Mute This Topic: https://lists.fd.io/mt/74750885/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] Interesting backtrace in 1908

[Christian Hopps]

FWIW, I cherry picked this w/o looking too close and hit the bug again, looked 
closer, this is not the fix. :)

The change for me is to the stack size for startup config node in 
src/vlib/unix/main.c

Thanks,
Chris.

> On Jun 6, 2020, at 4:34 AM, Andrew Yourtchenko  wrote:
> 
> https://gerrit.fd.io/r/c/vpp/+/27457
> 
> It was in that bunch of “catch up cherrypicks” that I was working on last 
> week.
> 
> --a
> 
>> On 5 Jun 2020, at 23:36, Dave Barach via lists.fd.io 
>>  wrote:
>> 
>> Dear Chris,
>> 
>> Whew, that just made my weekend a lot happier. 
>> 
>> I'll look into why the relevant patch didn't make it back into 19.08 - it 
>> will now! - unfortunately "stuff happens..."
>> 
>> Thanks for confirming... Dave
>> 
>> -Original Message-
>> From: Christian Hopps  
>> Sent: Friday, June 5, 2020 5:09 PM
>> To: Dave Barach (dbarach) 
>> Cc: Christian Hopps ; vpp-dev 
>> Subject: Re: [vpp-dev] Interesting backtrace in 1908
>> 
>> Bingo.
>> 
>> In fact in 19.08 the value is left as 0 which defaults to 15. I took it from 
>> 20 down to 15, starting successfully until I reached 15 which then hit the 
>> problem (both with the arp path and the other).
>> 
>> Thanks for the help finding this!
>> 
>> Chris.
>> 
>>> On Jun 5, 2020, at 4:52 PM, Dave Barach via lists.fd.io 
>>>  wrote:
>>> 
>>> Hmmm. That begins to smell like an undetected stack overflow. To test that 
>>> theory: s/18/20/ below: 
>>> 
>>> /* *INDENT-OFF* */
>>> VLIB_REGISTER_NODE (startup_config_node,static) = {
>>>   .function = startup_config_process,
>>>   .type = VLIB_NODE_TYPE_PROCESS,
>>>   .name = "startup-config-process",
>>>   .process_log2_n_stack_bytes = 18,
>>> };
>>> /* *INDENT-ON* */
>>> 
>>> It's entirely possible that compiling -O0 blows the stack, especially if 
>>> you end up 75 miles deep in fib code.
>>> 
>>> Dave
>>> 
>>> -Original Message-
>>> From: Christian Hopps 
>>> Sent: Friday, June 5, 2020 4:28 PM
>>> To: Dave Barach (dbarach) 
>>> Cc: Christian Hopps ; vpp-dev 
>>> Subject: Re: [vpp-dev] Interesting backtrace in 1908
>>> 
>>> 
>>> 
 On Jun 5, 2020, at 2:10 PM, Dave Barach via lists.fd.io 
  wrote:
 
 Step 1 is to make the silly-looking sibling recursion in 
 vlib_node_add_next_with_slot(...) disappear. I’m on it...
 
 Just to ask, can you repro w/ master/latest?
>>> 
>>> I will try and do this.
>>> 
>>> In the meantime I moved the arp configs to later in my startup config (this 
>>> is actually built by a test script) and immediately hit another sigsegv in 
>>> startup. This one is in infra but is going through my code initialization, 
>>> but also rooted in startup config processing... It's also in memcpy code, 
>>> which is making me suspicious now.
>>> 
>>> Again, I've changed "-O2" to "-O0" in the cmake vpp.mk package, when I 
>>> change it back to -O2 I do not hit either bug. So I'm now wondering if 
>>> there is something wrong with doing this, like do I need to do something 
>>> else as well?
>>> 
>>> What I'm going for is not to have CLIB_DEBUG defined, but still have useful 
>>> levels of debugabillity to do RCA on a much (millions of packets) later 
>>> problem I have.
>>> 
>>> modified   build-data/platforms/vpp.mk
>>> @@ -35,13 +35,21 @@ vpp_debug_TAG_CFLAGS = -O0 -DCLIB_DEBUG 
>>> $(vpp_common_cflags)  vpp_debug_TAG_CXXFLAGS = -O0 -DCLIB_DEBUG 
>>> $(vpp_common_cflags)  vpp_debug_TAG_LDFLAGS = -O0 -DCLIB_DEBUG 
>>> $(vpp_common_cflags)
>>> 
>>> -vpp_TAG_CFLAGS = -O2 $(vpp_common_cflags) -vpp_TAG_CXXFLAGS = -O2 
>>> $(vpp_common_cflags) -vpp_TAG_LDFLAGS = -O2 $(vpp_common_cflags) -pie
>>> +vpp_TAG_CFLAGS = -O0 $(vpp_common_cflags) vpp_TAG_CXXFLAGS = -O0
>>> +$(vpp_common_cflags) vpp_TAG_LDFLAGS = -O0 $(vpp_common_cflags) -pie
>>> 
>>> The new backtrace I'm seeing is:
>>> 
>>> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
>>> 0x75cbe8b1 in clib_mov16 (dst=0x6d986a57 >> access memory at address 0x6d986a57>, src=0x2d8f076c2d08 
>>> ) at 
>>> /var/build/vpp/src/vppinfra/memcpy_sse3.h:56
>>> 
>>> (gdb) bt
>>> #0  0x75cbe8b1 in clib_mov16 (dst=0x6d986a57 >> Cannot access memory at address 0x6d986a57>, 
>>> src=0x2d8f076c2d08 >> 0x2d8f076c2d08>) at /var/build/vpp/src/vppinfra/memcpy_sse3.h:56
>>> #1  0x75cbe910 in clib_mov32 (dst=0x7fffb90bea90 "", 
>>> src=0x7fffafa01fd0 "iptfs-refill-zpool sa_index %d before %d requested 
>>> %d head %d tail %d") at /var/build/vpp/src/vppinfra/memcpy_sse3.h:66
>>> #2  0x75cbe951 in clib_mov64 (dst=0x7fffb90bea90 "", 
>>> src=0x7fffafa01fd0 "iptfs-refill-zpool sa_index %d before %d requested 
>>> %d head %d tail %d") at /var/build/vpp/src/vppinfra/memcpy_sse3.h:73
>>> #3  0x75cbed5a in clib_memcpy_fast (dst=0x7fffb90bea90, 
>>> src=0x7fffafa01fd0, n=5) at 
>>> /var/build/vpp/src/vppinfra/memcpy_sse3.h:273
>>> #4  0x75cc5e72 in do_percent (_s=0x7fffb8141a58, 
>>> fmt=0x75dc7734 "%s%c", va=0x7fffb8141bc8) at 
>>> /var/build/vpp/src/vppinfr

Re: [vpp-dev] received signal SIGSEGV (vppinfra/time_range.h) no such file or directory

[Pac Ette]

Thanks Dave!

On Sun, Jun 7, 2020 at 6:42 AM Dave Barach (dbarach) 
wrote:

> https://gerrit.fd.io/r/c/vpp/+/27458. Next time you find something like
> this, feel free to fix it and push a patch.
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Pac Ette
> *Sent:* Saturday, June 6, 2020 4:15 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] received signal SIGSEGV (vppinfra/time_range.h) no
> such file or directory
>
>
>
> Hi all,
>
>
>
> I encountered this error today while using:
>
> vppctl sh mactime
>
>
>
> problem in *vpp v20.05 compiled from stable/2005 branch.*
>
> working fine in vpp v20.01
>
>
>
> *gdb:*
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x7fffad33f563 in clib_timebase_now (tb=)
> at /root/vpp/src/vppinfra/time_range.h:92
> 92 /root/vpp/src/vppinfra/time_range.h: No such file or directory.
>
> *syslog:*
> 2020-06-05T23:19:08.276917+00:00 333c55ab vnet[16756]: received signal
> SIGSEGV, PC 0x7f21e5c44563, faulting address 0x28
> 2020-06-05T23:19:08.278486+00:00 333c55ab vnet[16756]: #0
>  0x7f222e6f96e5 0x7f222e6f96e5
> 2020-06-05T23:19:08.279024+00:00 333c55ab vnet[16756]: #1
>  0x7f222df4f890 0x7f222df4f890
> 2020-06-05T23:19:08.279146+00:00 333c55ab vnet[16756]: #2
>  0x7f21e5c44563 0x7f21e5c44563
> 2020-06-05T23:19:08.279636+00:00 333c55ab vnet[16756]: #3
>  0x7f222e670762 0x7f222e670762
> 2020-06-05T23:19:08.279757+00:00 333c55ab vnet[16756]: #4
>  0x7f222e670679 0x7f222e670679
> 2020-06-05T23:19:08.279861+00:00 333c55ab vnet[16756]: #5
>  0x7f222e66fde0 vlib_cli_input + 0x80
> 2020-06-05T23:19:08.280377+00:00 333c55ab vnet[16756]: #6
>  0x7f222e6e9a4b 0x7f222e6e9a4b
> 2020-06-05T23:19:08.280499+00:00 333c55ab vnet[16756]: #7
>  0x7f222e699cc7 0x7f222e699cc7
> 2020-06-05T23:19:08.280968+00:00 333c55ab vnet[16756]: #8
>  0x7f222dadf3f4 0x7f222dadf3f4
>
>
>
> Thanks!
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Dynamically adding a node between two nodes

[Prashanth Fernando]

Hi,

I am pretty new to VPP and trying to understand few things


  *   Can I add a node in middle of a packet processing graph in runtime.

Eg: In the packet graph mentioned below, if I decide to add packet validation 
in runtime

Packet processing graph from ethernet-input -> ip4-input changed to   
ethernet-input -> packet-validatation -> ip4-input



  *   Also can we have core affinity for nodes.

Say I have node-1 running in core-2 and node-2 running in core-3 etc ...


Request for some pointers in this regard.

Thanks in advance,
Prashanth
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Vapi causes vpp to crash #vapi

[carol1311596199]

When I call *vapi_cpp_test or* vapi_c_test multiple times to test vapi, vpp 
crashes 。

vpp version : v20.01.1.0-2~g6d190dd

Following is crash gdb session transcript:

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x76177c0d in ok_magic (m=0xdeaddabe) at 
/data/zj/vpp/src/vppinfra/dlmalloc.c:1623
1623        return (m->magic == mparams.magic);
(gdb) bt
#0  0x76177c0d in ok_magic (m=0xdeaddabe) at 
/data/zj/vpp/src/vppinfra/dlmalloc.c:1623
#1  0x7617fd08 in mspace_free (msp=0x130047010, mem=0x1301c7e40) at 
/data/zj/vpp/src/vppinfra/dlmalloc.c:4489
#2  0x7617f232 in mspace_put (msp=0x130047010, p_arg=0x1301c7e44) at 
/data/zj/vpp/src/vppinfra/dlmalloc.c:4321
#3  0x77b95304 in clib_mem_free (p=0x1301c7e44) at 
/data/zj/vpp/src/vppinfra/mem.h:238
#4  0x77b95df4 in vl_msg_api_free_w_region (vlib_rp=0x130026000, 
a=0x1301c7e54) at /data/zj/vpp/src/vlibmemory/memory_shared.c:306
#5  0x77b95e38 in vl_msg_api_free (a=0x1301c7e54) at 
/data/zj/vpp/src/vlibmemory/memory_shared.c:314
#6  0x77bc5072 in vl_msg_api_handler_with_vm_node (am=0x77dd5e60 
, vlib_rp=0x130026000, the_msg=0x1301c7e54, vm=0x768ce480 
, node=0x7fffb5c23000,
is_private=0 '\000') at /data/zj/vpp/src/vlibapi/api_shared.c:622
#7  0x77b93fb9 in void_mem_api_handle_msg_i (am=0x77dd5e60 
, vlib_rp=0x130026000, vm=0x768ce480 , 
node=0x7fffb5c23000, is_private=0 '\000')
at /data/zj/vpp/src/vlibmemory/memory_api.c:698
#8  0x77b94005 in vl_mem_api_handle_msg_main (vm=0x768ce480 
, node=0x7fffb5c23000) at 
/data/zj/vpp/src/vlibmemory/memory_api.c:709
#9  0x77bafee6 in vl_api_clnt_process (vm=0x768ce480 
, node=0x7fffb5c23000, f=0x0) at 
/data/zj/vpp/src/vlibmemory/vlib_api.c:327
#10 0x7663103f in vlib_process_bootstrap (_a=140736271608784) at 
/data/zj/vpp/src/vlib/main.c:1475
#11 0x760f0240 in clib_calljmp () at 
/data/zj/vpp/src/vppinfra/longjmp.S:123
#12 0x7fffb779eba0 in ?? ()
#13 0x76631147 in vlib_process_startup (vm=0x76631aeb 
, p=0x7fffb779eca0, f=0x) at 
/data/zj/vpp/src/vlib/main.c:1497
#14 0x189ecf86e039 in ?? ()
#15 0x7fffb5c23000 in ?? ()
#16 0x7fffb65bfb18 in ?? ()
#17 0x7fffb65bf8a8 in ?? ()
#18 0x0018 in ?? ()
#19 0x7fffb65bfb18 in ?? ()
#20 0x7fffb5c23000 in ?? ()
#21 0x7fffb77c6764 in ?? ()
#22 0x in ?? ()

Thank you in advance!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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