date:20200803

Re: [vpp-dev] address sanitizer and unit tests not working

2020-08-03 Thread Benoit Ganne (bganne) via lists.fd.io

Hi Christian,

you need https://gerrit.fd.io/r/c/vpp/+/27268 or you can recompile with gcc 
instead.
There are a couple of crashes still, here are some fixes you might want to 
apply first:
 - https://gerrit.fd.io/r/c/vpp/+/27962
 - https://gerrit.fd.io/r/c/vpp/+/27963
 - https://gerrit.fd.io/r/c/vpp/+/27959

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Christian
> Hopps
> Sent: samedi 1 août 2020 00:54
> To: vpp-dev 
> Cc: Christian Hopps 
> Subject: [vpp-dev] address sanitizer and unit tests not working
> 
> Hi,
> 
> I'm trying to run the unit test with address sanitizer enabled but it's
> failing to run on the latest master for me. This is building on ubuntu
> 18.04 with clang-9 installed, the build used the same sanitizer make
> option too.
> 
> Any suggestions?
> 
> Thanks,
> Chris.
> 
> [18:51:50 dak:/var/build/vpp]$ make test-debug VPP_EXTRA_CMAKE_ARGS=-
> DVPP_ENABLE_SANITIZE_ADDR=ON
> make -C /var/build/vpp/build-root PLATFORM=vpp TAG=vpp_debug vpp-install
> make[1]: Entering directory '/var/build/vpp/build-root'
>  Arch for platform 'vpp' is native 
>  Finding source for external 
>  Makefile fragment found in /var/build/vpp/build-
> data/packages/external.mk 
>  Source found in /var/build/vpp/build 
>  Arch for platform 'vpp' is native 
>  Finding source for vpp 
>  Makefile fragment found in /var/build/vpp/build-data/packages/vpp.mk
> 
>  Source found in /var/build/vpp/src 
>  Configuring external: nothing to do 
>  Building external: nothing to do 
>  Installing external: nothing to do 
>  Configuring vpp: nothing to do 
>  Building vpp in /var/build/vpp/build-root/build-vpp_debug-native/vpp
> 
> ninja: no work to do.
>  Installing vpp: nothing to do 
> make[1]: Leaving directory '/var/build/vpp/build-root'
> make -C test VPP_BUILD_DIR=/var/build/vpp/build-root/build-vpp_debug-
> native VPP_BIN=/var/build/vpp/build-root/install-vpp_debug-
> native/vpp/bin/vpp VPP_PLUGIN_PATH=/var/build/vpp/build-root/install-
> vpp_debug-native/vpp/lib/vpp_plugins:/var/build/vpp/build-root/install-
> vpp_debug-native/vpp/lib64/vpp_plugins
> VPP_TEST_PLUGIN_PATH=/var/build/vpp/build-root/install-vpp_debug-
> native/vpp/lib/vpp_api_test_plugins:/var/build/vpp/build-root/install-
> vpp_debug-native/vpp/lib64/vpp_api_test_plugins
> VPP_INSTALL_PATH=/var/build/vpp/build-root/install-vpp_debug-native/
> LD_LIBRARY_PATH=/var/build/vpp/build-root/install-vpp_debug-
> native/vpp/lib/:/var/build/vpp/build-root/install-vpp_debug-
> native/vpp/lib64/ EXTENDED_TESTS= PYTHON= OS_ID=ubuntu
> RND_SEED=1596235925.011464 CACHE_OUTPUT= test
> make[1]: Entering directory '/var/build/vpp/test'
> ls: cannot access '/var/build/vpp/src/plugins/sctp/test/*.py': No such
> file or directory
> make -C ext test-apps
> make[2]: Entering directory '/var/build/vpp/test/ext'
> cc -o /var/build/vpp/build-root/build-test/vapi_test/vapi_c_test -
> std=gnu99 -g -Wall -lstdc++ -pthread -I/var/build/vpp/src -
> I/var/build/vpp/build-root/install-vpp_debug-native//vpp/include -
> I/var/build/vpp/build-root/build-test/vapi_test
> /var/build/vpp/test/ext/vapi_c_test.c -L/var/build/vpp/build-root/install-
> vpp_debug-native//vpp/lib -lvppinfra -lvlibmemoryclient -lsvm -lpthread -
> lcheck -lrt -lm -lvapiclient -lsubunit
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_report_store_n'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_report_load8'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_report_load2'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_report_load4'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_set_shadow_f8'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_stack_malloc_2'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_unregister_globals'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_stack_malloc_4'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_stack_free_5'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_register_globals'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_set_shadow_00'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/lib/libvppinfra.so: undefined reference to
> `__asan_stack_malloc_0'
> /var/build/vpp/build-root/install-vpp_debug-
> native//vpp/l

Re: [vpp-dev] vpp without dpdk

2020-08-03 Thread Benoit Ganne (bganne) via lists.fd.io

Hi,

> i am trying to bring vpp into user space without having dpdk  dependancy
> for interfaces. Is this feasible with socket listener on vpp hoststack?

It depends which interfaces you want to use. You can use interfaces with other 
drivers than DPDK:
 - AVF for Intel Fortville (i40e): 
https://docs.fd.io/vpp/20.09/d1/def/avf_plugin_doc.html
 - RDMA for Mellanox ConnectX4/5 (mlx5): 
https://docs.fd.io/vpp/20.09/df/d0e/rdma_doc.html
 - vmxnet3, virtio for paravirtualized interfaces
 - tap/tun

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

View/Reply Online (#17125): https://lists.fd.io/g/vpp-dev/message/17125
Mute This Topic: https://lists.fd.io/mt/75960555/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] Create big tables on huge-page

2020-08-03 Thread Lijian Zhang

Hi Nitin,
Both 2M and 1G are supported by pmalloc, but they are not supported at same 
time, as system is configured with either 2M or 1G hugepages, not both at the 
same time.
Thanks.
From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena via 
lists.fd.io
Sent: 2020年7月29日 15:23
To: Honnappa Nagarahalli ; Damjan Marion 

Cc: Lijian Zhang ; vpp-dev ; nd 
; Govindarajan Mohandoss ; 
Jieqiang Wang 
Subject: Re: [vpp-dev] Create big tables on huge-page

Hi Lijian,

+1 on the finding. It would be interested to know how much is the performance 
gain.
Having said that, correct me if I am wrong,  I think pmalloc module works only 
on single hugepage size (pm->def_log2_page_sz) which means either 1G or 2M and 
not both

Thanks,
Nitin

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Honnappa 
Nagarahalli
Sent: Thursday, July 23, 2020 10:53 PM
To: Damjan Marion mailto:dmar...@me.com>>
Cc: Lijian Zhang mailto:lijian.zh...@arm.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; nd 
mailto:n...@arm.com>>; Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>; 
Jieqiang Wang mailto:jieqiang.w...@arm.com>>; Honnappa 
Nagarahalli mailto:honnappa.nagaraha...@arm.com>>
Subject: [EXT] Re: [vpp-dev] Create big tables on huge-page

External Email

Sure. We will create couple of patches (in the areas we are analyzing 
currently) and we can decide from there.
Thanks,
Honnappa

From: Damjan Marion mailto:dmar...@me.com>>
Sent: Thursday, July 23, 2020 12:17 PM
To: Honnappa Nagarahalli 
mailto:honnappa.nagaraha...@arm.com>>
Cc: Lijian Zhang mailto:lijian.zh...@arm.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; nd 
mailto:n...@arm.com>>; Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>; 
Jieqiang Wang mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] Create big tables on huge-page

Hard to say without seeing the patch. Can you summarize what the changes will 
be in each particular .c file?

On 23 Jul 2020, at 18:00, Honnappa Nagarahalli 
mailto:honnappa.nagaraha...@arm.com>> wrote:

Hi Damjan,
Thank you. Till your patch is ready, would you accept patches 
that would enable creating these tables in 1G huge pages as temporary solution?

Thanks,
Honnappa

From: Damjan Marion mailto:dmar...@me.com>>
Sent: Thursday, July 23, 2020 7:15 AM
To: Lijian Zhang mailto:lijian.zh...@arm.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; nd 
mailto:n...@arm.com>>; Honnappa Nagarahalli 
mailto:honnappa.nagaraha...@arm.com>>; 
Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>; 
Jieqiang Wang mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] Create big tables on huge-page

I started working on patch which addresses most of this points, few weeks ago, 
but likely I will not have it completed for 20.09.
Even if it is completed, it is probably bad idea to merge it so late in the 
release process….

—
Damjan

On 23 Jul 2020, at 10:45, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:

Hi Maintainers,
From VPP source code, ip4-mtrie table is created on huge-page only when below 
parameters are set in configuration file.
While adjacency table is created on normal-page always.
  36 ip {
  37   heap-size 256M
  38   mtrie-hugetlb
  39 }
In the 10K flow testing, I configured 10K routing entries in ip4-mtrie and 10K 
entries in adjacency table.
By creating ip4-mtrie table on 1G huge-page with above parameters set and 
similarly create adjacency table on 1G huge-page, although I don’t observe 
obvious throughput performance improvement, but TLB misses are dramatically 
reduced.
Do you think configuration of 10K routing entries + 10K adjacency entries is a 
reasonable and possible config, or normally it would be 10K routing entries + 
only several adjacency entries?
Does it make sense to create adjacency table on huge-pages?
Another problem is although above assigned heap-size is 256M, but on 1G 
huge-page system, it seems to occupy a huge-page completely, other memory space 
within that huge-page seems will not be used by other tables.

Same as the bihash based tables, only 2M huge-page system is supported. To 
support creating bihash based tables on 1G huge-page system, each table will 
occupy a 1G huge-page completely, but that will waste a lot of memories.
Is it possible just like pmalloc module, reserving a big memory space on 1G/2M 
huge-pages in initialization stage, and then allocate memory pieces per 
requirement for Bihash, ip4-mtrie and adjacency tables, so that all tables 
could be created on huge-pages and will fully utilize the huge-pages.
I tried to create MAC table on 1G huge-page, and it does improve throughput 
performance.
vpp# show bihash
Name Actual Configured
GBP Endpoints - MAC/BD   1m 1m
b4s 64m 64m
b4s 64m 64m
in2out   10.12m 10.12m
in2out   10.12m 10.12

[vpp-dev] VLAN tags stripped and packets dropped

2020-08-03 Thread Mateusz Kowalski


Hello everyone,

I have a problem with VLANs being stripped off when using DPDK i40e 
driver with Intel X710 10GbE even though I'm not enabling stripping in 
my setup. The stripping happens as soon as I create a sub-interface. The 
summary of the observed behaviour is as follows


 * no sub-interfaces, `vlan offload: strip off filter off qinq off`,
   pcap and trace [1] show proper VLAN tag on the packet received
 * sub-interface created with a VLAN 979, `vlan offload: strip off
   filter on qinq off`, pcap and trace [2] shows the packet received
   without any VLAN with PKT_RX_VLAN_STRIPPED flag present
 * no configuration regarding VLAN stripping is in place [3] [6]

This problem resembles very much an issue from a few years ago - 
http://mails.dpdk.org/archives/dev/2016-May/039694.html - but I did not 
find anything back then what would help me resolve that one here. VPP 
used is v20.05. What happens effectively is that I can't use this 
interface with VLAN - as soon as I set an IP address on the 
sub-interface [4] and try reaching it from the outside, it fails to 
exchange ARPs [5] because the traffic enters the main interface instead 
of sub-interface.


Thanks for any advice on how to proceed or whether I can debug anything 
more to provide more info.


Best,
Mateusz

[1]
Packet 2
00:00:25:799112: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9bd41: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x101

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x26f50c0

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
  ARP: 48:df:37:b9:5d:90 -> ff:ff:ff:ff:ff:ff 802.1q vlan 979
  request, type ethernet/IP4, address size 6/4
  48:df:37:b9:5d:90/152.88.1.8 -> 00:00:00:00:00:00/152.88.1.3
00:00:25:799114: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 48:df:37:b9:5d:90 -> ff:ff:ff:ff:ff:ff 802.1q vlan 979
00:00:25:799114: error-drop
  rx:eno5vf0chocobomb
00:00:25:799115: drop
  ethernet-input: unknown vlan

[2]
Packet 34
20:34:17:437905: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9ee4f: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x121

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x1c1, data_off 128, phys_addr 
0x27b9440

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet
  PKT_RX_VLAN_STRIPPED (0x0040) RX packet VLAN tag stripped
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
...

[3]
>  dpdk {
>  dev :b2:02.0 {
>    name eno5vf0chocobomb
>  }
>  uio-driver vfio-pci
>  }

[4]
# show interface address
eno5vf0chocobomb (up):
eno5vf0chocobomb.979 (up):
  L3 152.88.1.3/28

[5]
20:34:17:437905: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9ee4f: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x121

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x1c1, data_off 128, phys_addr 
0x27b9440

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet
  PKT_RX_VLAN_STRIPPED (0x0040) RX packet VLAN tag stripped
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
  ARP: 48:df:37:b8:fe:a0 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  48:df:37:b8:fe:a0/152.88.1.7 -> 00:00:00:00:00:00/152.88.1.3
20:34:17:437906: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 48:df:37:b8:fe:a0 -> ff:ff:ff:ff:ff:ff
20:34:17:437906: arp-input
  request, type ethernet/IP4, address size 6/4
  48:df:37:b8:fe:a0/152.88.1.7 -> 00:00:00:00:00:00/152.88.1.3
20:34:17:437907: arp-disabled
  request, type ethernet/IP4, address size 6/4
  48:df:37:b8:fe:a0/152.88.1.7 -> 00:00:00:00:00:00/152.88.1.3
20:34:17:437907: error-drop
  rx:eno5vf0chocobomb
20:34:17:437907: drop
  arp-disabled: ARP Disabled on

Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp

2020-08-03 Thread Solis JR, M. (Mauricio) via lists.fd.io

Justin,
Do you know the release date for the updated iOAM plugin on the latest ietf 
draft?

Mauricio

-Original Message-
From: Justin Iurman  
Sent: woensdag 29 juli 2020 14:26
To: Solis JR, M. (Mauricio) 
Cc: vpp-dev ; Shwetha Bhandari (shwethab) 

Subject: Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp

Hi Mauricio,

CC'ing Shwetha, she implemented the IOAM plugin. Last time I checked, IOAM 
namespaces were not included, so it is probably based on the -03 version of 
draft-ietf-ippm-ioam-data. Actually, just to let you know, there is already 
someone that is going to rebase the implementation on the last draft version.

Justin

> Hi,
> 
> I noticed that the current iOAM plugin implementation is using the 
> first IETF drafts, so I'm thinking about trying to update the iOAM 
> implementation in VPP using the latest. I first just want to make sure 
> there that this update is not in the immediate VPP release pipeline 
> since I do not wish to do work that has already been done. I'm also 
> uncertain about the amount of work it will require to update the 
> plugin, but I have already dug into the code and it doesn't seem "too" bad.
> 
> Regards,
> 
> Mauricio
This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp

2020-08-03 Thread Justin Iurman

Mauricio,

> Justin,
> Do you know the release date for the updated iOAM plugin on the latest ietf
> draft?

Not really. This is actually a student and he's going to do it for his master 
thesis. Who knows for the precise date, but he will start soon... so I'd say 
during first 2021 semester (or trimester hopefully).

Out of curiosity, what are you working on with IOAM so that you want to refresh 
the VPP implem?

Justin

> Mauricio
> 
> -Original Message-
> From: Justin Iurman 
> Sent: woensdag 29 juli 2020 14:26
> To: Solis JR, M. (Mauricio) 
> Cc: vpp-dev ; Shwetha Bhandari (shwethab)
> 
> Subject: Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp
> 
> Hi Mauricio,
> 
> CC'ing Shwetha, she implemented the IOAM plugin. Last time I checked, IOAM
> namespaces were not included, so it is probably based on the -03 version of
> draft-ietf-ippm-ioam-data. Actually, just to let you know, there is already
> someone that is going to rebase the implementation on the last draft version.
> 
> Justin
> 
>> Hi,
>> 
>> I noticed that the current iOAM plugin implementation is using the
>> first IETF drafts, so I'm thinking about trying to update the iOAM
>> implementation in VPP using the latest. I first just want to make sure
>> there that this update is not in the immediate VPP release pipeline
>> since I do not wish to do work that has already been done. I'm also
>> uncertain about the amount of work it will require to update the
>> plugin, but I have already dug into the code and it doesn't seem "too" bad.
>> 
>> Regards,
>> 
>> Mauricio
> This message may contain information that is not intended for you. If you are
> not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no 
> liability
> for the content of this e-mail, for the manner in which you use it and for
> damage of any kind resulting from the risks inherent to the electronic
> transmission of messages.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] VPP 2005 is crashing on stopping the VCL applications #vpp-hoststack

2020-08-03 Thread Raj Kumar

Hi Florin,
This issue is resolved now.  In my application, on receiving the kill
signal main thread was sending phread_cancel() to the child thread
because of that child thread was not exiting gracefully.
I have one question; it seems that vppcom_epoll_wait(epfd, rcvEvents,
MAX_RETURN_EVENTS, 6.0) is not returning after timed out if the timeout
value is a non zero value. It timed out only if the timeout value is 0.
The issue that I am facing is that if there is no traffic at all ( receiver
is just listening on the connections ) then the worker thread is not
exiting as it is blocked by vppcom_epoll_wait().

Thanks,
-Raj



On Wed, Jul 29, 2020 at 11:23 PM Florin Coras 
wrote:

> Hi Raj,
>
> In that case it should work. Just from the trace lower it’s hard to figure
> out what exactly happened. Also, keep in mind that vcl is not thread safe,
> so make sure you’re not trying to share sessions or allow two workers to
>  interact with the message queue(s) at the same time.
>
> Regards,
> Florin
>
> On Jul 29, 2020, at 8:17 PM, Raj Kumar  wrote:
>
> Hi Florin,
> I am using kill  to stop the application. But , the application has a
> kill signal handler and after receiving the signal it is exiting gracefully.
> About vppcom_app_exit, I think this function is registered with atexit()
> inside vppcom_app_create() so it should call when the application exits.
> Even, I also tried this vppcom_app_exit() explicitly before exiting the
> application but still I am seeing the same issue.
>
> My application is a multithreaded application. Can you please suggest some
> cleanup functions ( vppcom functions) that  I should call before exiting a
> thread and the main application for a proper cleanup.
> I also tried vppcom_app_destroy() before exiting the main application but
> still I am seeing the same issue.
>
> thanks,
> -Raj
>
> On Wed, Jul 29, 2020 at 5:34 PM Florin Coras 
> wrote:
>
>> Hi Raj,
>>
>> Does stopping include a call to vppcom_app_exit or killing the
>> applications? If the latter, the apps might be killed with some
>> mutexes/spinlocks held. For now, we only support the former.
>>
>> Regards,
>> Florin
>>
>> > On Jul 29, 2020, at 1:49 PM, Raj Kumar  wrote:
>> >
>> > Hi,
>> > In my UDP application , I am using VPP host stack to receive packets
>> and memIf to transmit packets. There are a total 6 application connected to
>> VPP.
>> > if I stop the application(s) then VPP is crashing.  In vpp
>> configuration , 4 worker threads are configured.  If there is no worker
>> thread configured then I do not see this crash.
>> > Here is the VPP task trace -
>> >  (gdb) bt
>> > #0  0x751818df in raise () from /lib64/libc.so.6
>> > #1  0x7516bcf5 in abort () from /lib64/libc.so.6
>> > #2  0xc123 in os_panic () at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vpp/vnet/main.c:366
>> > #3  0x76b466bb in vlib_worker_thread_barrier_sync_int
>> (vm=0x76d78200 , func_name=)
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/threads.c:1529
>> > #4  0x77bc5ef0 in vl_msg_api_handler_with_vm_node 
>> > (am=am@entry=0x77dd2ea0
>> ,
>> > vlib_rp=vlib_rp@entry=0x7fee7c001000, the_msg=0x7fee7c02bbd8,
>> vm=vm@entry=0x76d78200 ,
>> > node=node@entry=0x7fffb6295000, is_private=is_private@entry=1
>> '\001')
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibapi/api_shared.c:596
>> > #5  0x77bb000f in void_mem_api_handle_msg_i (is_private=1
>> '\001', node=0x7fffb6295000, vm=0x76d78200 ,
>> > vlib_rp=0x7fee7c001000, am=0x77dd2ea0 )
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:698
>> > #6  vl_mem_api_handle_msg_private (vm=vm@entry=0x76d78200
>> , node=node@entry=0x7fffb6295000, reg_index=> out>)
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:762
>> > #7  0x77bbe346 in vl_api_clnt_process (vm=,
>> node=0x7fffb6295000, f=)
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/vlib_api.c:370
>> > #8  0x76b161d6 in vlib_process_bootstrap (_a=)
>> > at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/main.c:1502
>> > #9  0x7602ac0c in clib_calljmp () from
>> /lib64/libvppinfra.so.20.05
>> > #10 0x7fffb5e93dd0 in ?? ()
>> > #11 0x76b19821 in dispatch_process (vm=0x76d78200
>> , p=0x7fffb6295000, last_time_stamp=15931923011231136,
>> > f=0x0) at
>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vppinfra/types.h:133
>> > #12 0x7f0f66009024 in ?? ()
>> >
>> >
>> > Thanks,
>> > -Raj
>> >
>>
>> 
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17130): https://lists.fd.io/g/vpp-dev/message/17130
Mute This Topic: https://lists.fd.io/mt/75873900/21656
Mute #vpp-hoststack: 
https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-hoststack
Group Owner: vpp-dev+ow...

Re: [vpp-dev] VPP 2005 is crashing on stopping the VCL applications #vpp-hoststack

2020-08-03 Thread Florin Coras

Hi Raj, 

Glad to hear that issue is solved. What vcl config are you running? Did you 
configure use-mq-eventd? 

Regards,
Florin

> On Aug 3, 2020, at 8:33 PM, Raj Kumar  wrote:
> 
> Hi Florin,
> This issue is resolved now.  In my application, on receiving the kill signal 
> main thread was sending phread_cancel() to the child thread because of that 
> child thread was not exiting gracefully. 
> I have one question; it seems that vppcom_epoll_wait(epfd, rcvEvents, 
> MAX_RETURN_EVENTS, 6.0) is not returning after timed out if the timeout 
> value is a non zero value. It timed out only if the timeout value is 0.
> The issue that I am facing is that if there is no traffic at all ( receiver 
> is just listening on the connections ) then the worker thread is not exiting 
> as it is blocked by vppcom_epoll_wait().
> 
> Thanks,
> -Raj
> 
> 
> 
> On Wed, Jul 29, 2020 at 11:23 PM Florin Coras  > wrote:
> Hi Raj, 
> 
> In that case it should work. Just from the trace lower it’s hard to figure 
> out what exactly happened. Also, keep in mind that vcl is not thread safe, so 
> make sure you’re not trying to share sessions or allow two workers to  
> interact with the message queue(s) at the same time. 
> 
> Regards,
> Florin
> 
>> On Jul 29, 2020, at 8:17 PM, Raj Kumar > > wrote:
>> 
>> Hi Florin,
>> I am using kill  to stop the application. But , the application has a 
>> kill signal handler and after receiving the signal it is exiting gracefully.
>> About vppcom_app_exit, I think this function is registered with atexit() 
>> inside vppcom_app_create() so it should call when the application exits. 
>> Even, I also tried this vppcom_app_exit() explicitly before exiting the 
>> application but still I am seeing the same issue. 
>> 
>> My application is a multithreaded application. Can you please suggest some 
>> cleanup functions ( vppcom functions) that  I should call before exiting a 
>> thread and the main application for a proper cleanup. 
>> I also tried vppcom_app_destroy() before exiting the main application but 
>> still I am seeing the same issue.
>> 
>> thanks,
>> -Raj
>> 
>> On Wed, Jul 29, 2020 at 5:34 PM Florin Coras > > wrote:
>> Hi Raj, 
>> 
>> Does stopping include a call to vppcom_app_exit or killing the applications? 
>> If the latter, the apps might be killed with some mutexes/spinlocks held. 
>> For now, we only support the former. 
>> 
>> Regards,
>> Florin
>> 
>> > On Jul 29, 2020, at 1:49 PM, Raj Kumar > > > wrote:
>> > 
>> > Hi,
>> > In my UDP application , I am using VPP host stack to receive packets and 
>> > memIf to transmit packets. There are a total 6 application connected to 
>> > VPP. 
>> > if I stop the application(s) then VPP is crashing.  In vpp configuration , 
>> > 4 worker threads are configured.  If there is no worker thread configured 
>> > then I do not see this crash.
>> > Here is the VPP task trace - 
>> >  (gdb) bt
>> > #0  0x751818df in raise () from /lib64/libc.so.6
>> > #1  0x7516bcf5 in abort () from /lib64/libc.so.6
>> > #2  0xc123 in os_panic () at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vpp/vnet/main.c:366
>> > #3  0x76b466bb in vlib_worker_thread_barrier_sync_int 
>> > (vm=0x76d78200 , func_name=)
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/threads.c:1529
>> > #4  0x77bc5ef0 in vl_msg_api_handler_with_vm_node 
>> > (am=am@entry=0x77dd2ea0 ,
>> > vlib_rp=vlib_rp@entry=0x7fee7c001000, the_msg=0x7fee7c02bbd8, 
>> > vm=vm@entry=0x76d78200 ,
>> > node=node@entry=0x7fffb6295000, is_private=is_private@entry=1 '\001')
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibapi/api_shared.c:596
>> > #5  0x77bb000f in void_mem_api_handle_msg_i (is_private=1 '\001', 
>> > node=0x7fffb6295000, vm=0x76d78200 ,
>> > vlib_rp=0x7fee7c001000, am=0x77dd2ea0 )
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:698
>> > #6  vl_mem_api_handle_msg_private (vm=vm@entry=0x76d78200 
>> > , node=node@entry=0x7fffb6295000, reg_index=> > out>)
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:762
>> > #7  0x77bbe346 in vl_api_clnt_process (vm=, 
>> > node=0x7fffb6295000, f=)
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/vlib_api.c:370
>> > #8  0x76b161d6 in vlib_process_bootstrap (_a=)
>> > at 
>> > /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/main.c:1502
>> > #9  0x7602ac0c in clib_calljmp () from /lib64/libvppinfra.so.20.05
>> > #10 0x7fffb5e93dd0 in ?? ()
>> > #11 0x76b19821 in dispatch_process (vm=0x76d78200 
>> > , p=0x7fffb6295000, last_time_stamp=15931923011231136,
>> > f=0x0) at 
>> > /usr/src/debug/vpp-20.05

Re: [vpp-dev] VLAN tags stripped and packets dropped

2020-08-03 Thread Mateusz Kowalski

To some extent answering my own question, I have found the following 
thread - http://mails.dpdk.org/archives/users/2018-June/003175.html - 
"[...] if adding vlan filter, the packet will be received with vlan 
stripped even if the vlan_strip is disabled. It’s i40e HW limitation, 
different from ixgbe"

I wonder if this has changed, though...

Another thing, more on the VPP side, would be a question whether I could 
explicitly disable offloading VLAN filter. Any ideas regarding this part?

Cheers,
Mateusz

On 03/08/2020 16:43, Mateusz Kowalski wrote:

Hello everyone,

I have a problem with VLANs being stripped off when using DPDK i40e 
driver with Intel X710 10GbE even though I'm not enabling stripping in 
my setup. The stripping happens as soon as I create a sub-interface. 
The summary of the observed behaviour is as follows

  * no sub-interfaces, `vlan offload: strip off filter off qinq off`,
pcap and trace [1] show proper VLAN tag on the packet received
  * sub-interface created with a VLAN 979, `vlan offload: strip off
filter on qinq off`, pcap and trace [2] shows the packet received
without any VLAN with PKT_RX_VLAN_STRIPPED flag present
  * no configuration regarding VLAN stripping is in place [3] [6]

This problem resembles very much an issue from a few years ago - 
http://mails.dpdk.org/archives/dev/2016-May/039694.html - but I did 
not find anything back then what would help me resolve that one here. 
VPP used is v20.05. What happens effectively is that I can't use this 
interface with VLAN - as soon as I set an IP address on the 
sub-interface [4] and try reaching it from the outside, it fails to 
exchange ARPs [5] because the traffic enters the main interface 
instead of sub-interface.

Thanks for any advice on how to proceed or whether I can debug 
anything more to provide more info.

Best,
Mateusz

[1]
Packet 2
00:00:25:799112: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9bd41: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x101

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x26f50c0

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
  ARP: 48:df:37:b9:5d:90 -> ff:ff:ff:ff:ff:ff 802.1q vlan 979
  request, type ethernet/IP4, address size 6/4
  48:df:37:b9:5d:90/152.88.1.8 -> 00:00:00:00:00:00/152.88.1.3
00:00:25:799114: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 48:df:37:b9:5d:90 -> ff:ff:ff:ff:ff:ff 802.1q vlan 979
00:00:25:799114: error-drop
  rx:eno5vf0chocobomb
00:00:25:799115: drop
  ethernet-input: unknown vlan

[2]
Packet 34
20:34:17:437905: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9ee4f: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x121

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x1c1, data_off 128, phys_addr 
0x27b9440

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet
  PKT_RX_VLAN_STRIPPED (0x0040) RX packet VLAN tag stripped
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
...

[3]
>  dpdk {
>  dev :b2:02.0 {
>    name eno5vf0chocobomb
>  }
>  uio-driver vfio-pci
>  }

[4]
# show interface address
eno5vf0chocobomb (up):
eno5vf0chocobomb.979 (up):
  L3 152.88.1.3/28

[5]
20:34:17:437905: dpdk-input
  eno5vf0chocobomb rx queue 0
  buffer 0x9ee4f: current data 0, length 60, buffer-pool 0, ref-count 
1, totlen-nifb 0, trace handle 0x121

  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x1c1, data_off 128, phys_addr 
0x27b9440

    packet_type 0x3 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
  PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet
  PKT_RX_VLAN_STRIPPED (0x0040) RX packet VLAN tag stripped
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
  RTE_PTYPE_L2_ETHER_ARP (0x0003) ARP packet
  ARP: 48:df:37:b8:fe:a0 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  48:d

Re: [vpp-dev] address sanitizer and unit tests not working

Re: [vpp-dev] vpp without dpdk

Re: [vpp-dev] Create big tables on huge-page

[vpp-dev] VLAN tags stripped and packets dropped

Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp

Re: [vpp-dev] Update to iOAM using latest IETF draft #vpp

Re: [vpp-dev] VPP 2005 is crashing on stopping the VCL applications #vpp-hoststack

Re: [vpp-dev] VPP 2005 is crashing on stopping the VCL applications #vpp-hoststack

Re: [vpp-dev] VLAN tags stripped and packets dropped

9 matches

Site Navigation

Mail list logo

Footer information