Hi Raj, Try maybe:
make wipe-release make build-release … Also, try removing all packages before reinstalling them to make sure that you’re including/linking against the right vppcom lib. Regards, Florin > On May 19, 2020, at 4:59 PM, Raj Kumar <raj.gauta...@gmail.com> wrote: > > Hi Florin, > I am facing a weird problem. After making the VPP code changes, I > recompiled/re-installed VPP by using the following commands- > make rebuild-release > make pkg-rpm > rpm -ivh /opt/vpp/build-root/*.rpm > > But, it looks that VPP is still using the old code I also stopped the VPP > service before compiling and installing the new code. > Also, recompiled the application using the new vppcom library. > But, the line# in the following trace indicates that VPP is using the old > code > vppcom_session_create:1279: vcl<28267:1>: created session 1 > > May be because of this issue , VPP is still crashing with UDPC. > > Please let me know if there is any other way to compile VPP with the local > code changes. > > thanks, > -Raj > . > > On Tue, May 19, 2020 at 12:31 AM Florin Coras <fcoras.li...@gmail.com > <mailto:fcoras.li...@gmail.com>> wrote: > Hi Raj, > > By the looks of it, something’s not right because in the logs VCL still > reports it’s binding using UDPC. You probably cherry-picked [1] but it needs > [2] as well. More inline. > > [1] https://gerrit.fd.io/r/c/vpp/+/27111 > <https://gerrit.fd.io/r/c/vpp/+/27111> > [2] https://gerrit.fd.io/r/c/vpp/+/27106 > <https://gerrit.fd.io/r/c/vpp/+/27106> > >> On May 18, 2020, at 8:42 PM, Raj Kumar <raj.gauta...@gmail.com >> <mailto:raj.gauta...@gmail.com>> wrote: >> >> >> Hi Florin, >> I tried the path [1] , but still VPP is crashing when application is using >> listen with UDPC. >> >> [1] https://gerrit.fd.io/r/c/vpp/+/27111 >> <https://gerrit.fd.io/r/c/vpp/+/27111> >> >> >> >> On a different topic , I have some questions. Could you please provide your >> inputs - >> >> 1) I am using Mellanox NIC. Any idea how can I enable Tx checksum offload ( >> for udp). Also, how to change the Tx burst mode and Rx burst mode to the >> Vector . >> >> HundredGigabitEthernet12/0/1 3 up HundredGigabitEthernet12/0/1 >> Link speed: 100 Gbps >> Ethernet address b8:83:03:9e:98:81 >> Mellanox ConnectX-4 Family >> carrier up full duplex mtu 9206 >> flags: admin-up pmd maybe-multiseg rx-ip4-cksum >> rx: queues 4 (max 1024), desc 1024 (min 0 max 65535 align 1) >> tx: queues 5 (max 1024), desc 1024 (min 0 max 65535 align 1) >> pci: device 15b3:1013 subsystem 1590:00c8 address 0000:12:00.01 numa 0 >> switch info: name 0000:12:00.1 domain id 1 port id 65535 >> max rx packet len: 65536 >> promiscuous: unicast off all-multicast on >> vlan offload: strip off filter off qinq off >> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum vlan-filter >> jumbo-frame scatter timestamp keep-crc rss-hash >> rx offload active: ipv4-cksum udp-cksum tcp-cksum jumbo-frame scatter >> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso >> outer-ipv4-cksum vxlan-tnl-tso gre-tnl-tso >> geneve-tnl-tso >> multi-segs udp-tnl-tso ip-tnl-tso >> tx offload active: multi-segs >> rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 >> ipv6-tcp-ex >> ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other >> ipv6-ex ipv6 l4-dst-only l4-src-only l3-dst-only >> l3-src-only >> rss active: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 >> ipv6-tcp-ex >> ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other >> ipv6-ex ipv6 >> tx burst mode: No MPW + MULTI + TSO + INLINE + METADATA >> rx burst mode: Scalar > > FC: Not sure why (might not be supported) but the offloads are not enabled in > dpdk_lib_init for VNET_DPDK_PMD_MLX* nics. You could try replicating what’s > done for the Intel cards and see if that works. Alternatively, you might want > to try the rdma driver, although I don’t know if it supports csum offloading > (cc Ben and Damjan). > >> >> 2) My application needs to send routing header (SRv6) and Destination option >> extension header. On RedHat 8.1 , I was using socket option to add routing >> and destination option extension header. >> With VPP , I can use SRv6 policy to let VPP add the routing header. But, I >> am not sure if there is any option in VPP or HostStack to add the >> destination option header. > > FC: We don’t currently support this. > > Regards, > Florin > >> >> >> Coming back to the original problem, here are the traces- >> >> VCL<39673>: configured VCL debug level (2) from VCL_DEBUG! >> VCL<39673>: using default heapsize 268435456 (0x10000000) >> VCL<39673>: allocated VCL heap = 0x7f6b40221010, size 268435456 (0x10000000) >> VCL<39673>: using default configuration. >> vppcom_connect_to_vpp:487: vcl<39673:0>: app (udp6_rx) connecting to VPP api >> (/vpe-api)... >> vppcom_connect_to_vpp:502: vcl<39673:0>: app (udp6_rx) is connected to VPP! >> vppcom_app_create:1200: vcl<39673:0>: sending session enable >> vppcom_app_create:1208: vcl<39673:0>: sending app attach >> vppcom_app_create:1217: vcl<39673:0>: app_name 'udp6_rx', my_client_index 0 >> (0x0) >> vppcom_connect_to_vpp:487: vcl<39673:1>: app (udp6_rx-wrk-1) connecting to >> VPP api (/vpe-api)... >> vppcom_connect_to_vpp:502: vcl<39673:1>: app (udp6_rx-wrk-1) is connected to >> VPP! >> vcl_worker_register_with_vpp:262: vcl<39673:1>: added worker 1 >> vl_api_app_worker_add_del_reply_t_handler:235: vcl<94:-1>: worker 1 >> vpp-worker 1 added >> vppcom_epoll_create:2558: vcl<39673:1>: Created vep_idx 0 >> vppcom_session_create:1279: vcl<39673:1>: created session 1 >> vppcom_session_bind:1426: vcl<39673:1>: session 1 handle 16777217: binding >> to local IPv6 address 2001:5b0:ffff:700:b883:31f:29e:9880 port 6677, proto >> UDPC >> vppcom_session_listen:1458: vcl<39673:1>: session 16777217: sending vpp >> listen request... >> >> #1 0x00007ffff7761259 in session_listen (ls=<optimized out>, >> sep=sep@entry=0x7fffb575ad50) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session_types.h:247 >> #2 0x00007ffff7788b5f in app_listener_alloc_and_init >> (app=app@entry=0x7fffb7273038, sep=sep@entry=0x7fffb575ad50, >> listener=listener@entry=0x7fffb575ad28) at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/application.c:196 >> #3 0x00007ffff7788ef8 in vnet_listen (a=a@entry=0x7fffb575ad50) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/application.c:1005 >> #4 0x00007ffff7779e20 in session_mq_listen_handler (data=0x13007ec01) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session_node.c:64 >> #5 session_mq_listen_handler (data=data@entry=0x13007ec01) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session_node.c:36 >> #6 0x00007ffff7bbcdd9 in vl_api_rpc_call_t_handler (mp=0x13007ebe8) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlibmemory/vlib_api.c:520 >> #7 0x00007ffff7bc5ecd in vl_msg_api_handler_with_vm_node >> (am=am@entry=0x7ffff7dd2ea0 <api_global_main>, vlib_rp=<optimized out>, >> the_msg=0x13007ebe8, vm=vm@entry=0x7ffff6d7c200 <vlib_global_main>, >> node=node@entry=0x7fffb571a000, is_private=is_private@entry=0 '\000') >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlibapi/api_shared.c:609 >> #8 0x00007ffff7baff06 in vl_mem_api_handle_rpc (vm=vm@entry=0x7ffff6d7c200 >> <vlib_global_main>, node=node@entry=0x7fffb571a000) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlibmemory/memory_api.c:748 >> #9 0x00007ffff7bbd5d3 in vl_api_clnt_process (vm=<optimized out>, >> node=0x7fffb571a000, f=<optimized out>) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlibmemory/vlib_api.c:326 >> #10 0x00007ffff6b1b136 in vlib_process_bootstrap (_a=<optimized out>) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:1502 >> #11 0x00007ffff602fc0c in clib_calljmp () from /lib64/libvppinfra.so.20.05 >> #12 0x00007fffb5e34dd0 in ?? () >> #13 0x00007ffff6b1e771 in vlib_process_startup (f=0x0, p=0x7fffb571a000, >> vm=0x7ffff6d7c200 <vlib_global_main>) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vppinfra/types.h:133 >> #14 dispatch_process (vm=0x7ffff6d7c200 <vlib_global_main>, >> p=0x7fffb571a000, last_time_stamp=12611933408198086, f=0x0) >> at >> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:1569 >> >> thanks, >> -Raj >> >> >> >> >> On Sat, May 16, 2020 at 8:18 PM Florin Coras <fcoras.li...@gmail.com >> <mailto:fcoras.li...@gmail.com>> wrote: >> Hi Raj, >> >> Inline. >> >>> On May 16, 2020, at 2:30 PM, Raj Kumar <raj.gauta...@gmail.com >>> <mailto:raj.gauta...@gmail.com>> wrote: >>> >>> Hi Florin, >>> >>> I am using VPP 20.05 rc0 . Should I upgrade it ? >> >> FC: Not necessarily, as long as it’s relatively recent, i.e., it includes >> all of the recent udp updates. >> >>> >>> Thanks! for providing the patch, i will try it on Monday. Actually, I am >>> testing in a controlled environment where I can not change the VPP >>> libraries. I will try it on my server. >> >> FC: Sounds good. Let me know how it goes! >> >>> >>> On the UDP connection; yes, the error EINPROGRESS was there because I am >>> using non-blocking connection. Now, I am ignoring this error. >>> Sometime , VPP crashes when I kills my application ( not gracefully) even >>> when there is a single connection . >> >> FC: That might have to do with the app dying such that 1) it does not detach >> from vpp (e.g., sigkill and atexit function is not executed) 2) it dies with >> the message queue mutex held and 3) vpp tries to enqueue more events before >> detecting that it crashed (~30s). >> >>> >>> The good part is that now I am able to move connections on different cores >>> by connecting it on receiving the first packet and then re-binding the >>> socket to listen. >>> Basically, this approach works but I have not tested it thoroughly. However >>> , I am still in favor of using the UDPC connection. >> >> FC: If you have enough logic in your app to emulate a handshake, i.e., >> always have the client send a few bytes and wait for a reply from the server >> before opening a new connection, then this approach is probably more >> flexible from core placement perspective. >> >> The patch tries to emulate the old udpc with udp (udpc in vpp was confusing >> for consumers). You might get away with listening from multiple vcl workers >> on the same udp ip:port pair and have vpp load balance accepts between them, >> but I’ve never tested that. You can do this only with udp listeners that >> have been initialized as connected (so only with the patch). >> >>> >>> Btw, in trace logs I see some ssvm_delete related error when re-binding the >>> connection. >> >> FC: I think it’s fine. Going over the interactions step by step to see if >> understand what you’re doing (and hopefully help you understand what vpp >> does underneath). >> >>> >>> vpp# sh session verbose >>> Connection State Rx-f >>> Tx-f >>> [0:0][U] 2001:5b0:ffff:700:b883:31f:29e:9880:6677-LISTEN 0 0 >>> Thread 0: active sessions 1 >>> >>> Connection State Rx-f >>> Tx-f >>> [1:0][U] 2001:5b0:ffff:700:b883:31f:29e:9880:6677-OPENED 0 0 >>> Thread 1: active sessions 1 >>> >>> Connection State Rx-f >>> Tx-f >>> [2:0][U] 2001:5b0:ffff:700:b883:31f:29e:9880:6677-OPENED 0 0 >>> Thread 2: active sessions 1 >>> Thread 3: no sessions >>> Thread 4: no sessions >>> >>> VCL<24434>: configured VCL debug level (2) from VCL_DEBUG! >>> VCL<24434>: using default heapsize 268435456 (0x10000000) >>> VCL<24434>: allocated VCL heap = 0x7f7f18d1b010, size 268435456 (0x10000000) >>> VCL<24434>: using default configuration. >>> vppcom_connect_to_vpp:487: vcl<24434:0>: app (udp6_rx) connecting to VPP >>> api (/vpe-api)... >>> vppcom_connect_to_vpp:502: vcl<24434:0>: app (udp6_rx) is connected to VPP! >>> vppcom_app_create:1200: vcl<24434:0>: sending session enable >>> vppcom_app_create:1208: vcl<24434:0>: sending app attach >>> vppcom_app_create:1217: vcl<24434:0>: app_name 'udp6_rx', my_client_index 0 >>> (0x0) >> >> FC: Added worker 0 >> >>> vppcom_connect_to_vpp:487: vcl<24434:1>: app (udp6_rx-wrk-1) connecting to >>> VPP api (/vpe-api)... >>> vppcom_connect_to_vpp:502: vcl<24434:1>: app (udp6_rx-wrk-1) is connected >>> to VPP! >>> vcl_worker_register_with_vpp:262: vcl<24434:1>: added worker 1 >> >>> vl_api_app_worker_add_del_reply_t_handler:235: vcl<94:-1>: worker 1 >>> vpp-worker 1 added >> >> FC: Adding worker 1 >> >>> vppcom_epoll_create:2558: vcl<24434:1>: Created vep_idx 0 >>> vppcom_session_create:1279: vcl<24434:1>: created session 1 >>> vppcom_session_bind:1426: vcl<24434:1>: session 1 handle 16777217: binding >>> to local IPv6 address 2001:5b0:ffff:700:b883:31f:29e:9880 port 6677, proto >>> UDP >>> vppcom_session_listen:1458: vcl<24434:1>: session 16777217: sending vpp >>> listen request... >>> vcl_session_bound_handler:607: vcl<24434:1>: session 1 [0x0]: listen >>> succeeded! >>> vppcom_epoll_ctl:2658: vcl<24434:1>: EPOLL_CTL_ADD: vep_sh 16777216, sh >>> 16777217, events 0x1, data 0xffffffff! >> >> FC: Listened on session 1 and added it to epoll session 0 >> >>> udpRxThread started!!! ... rx port = 6677 >>> Waiting for a client to connect on port 6677 ... >>> vppcom_session_connect:1742: vcl<24434:1>: session handle 16777217 >>> (STATE_CLOSED): connecting to peer IPv6 2001:5b0:ffff:700:b883:31f:29e:9886 >>> port 40300 proto UDP >> >> FC: I guess at this point you got data on the listener so you now try to >> connect it to the peer. >> >>> vppcom_epoll_ctl:2696: vcl<24434:1>: EPOLL_CTL_MOD: vep_sh 16777216, sh >>> 16777217, events 0x2011, data 0x1000001! >> >>> vppcom_session_create:1279: vcl<24434:1>: created session 2 >>> vppcom_session_bind:1426: vcl<24434:1>: session 2 handle 16777218: binding >>> to local IPv6 address 2001:5b0:ffff:700:b883:31f:29e:9880 port 6677, proto >>> UDP >>> vppcom_session_listen:1458: vcl<24434:1>: session 16777218: sending vpp >>> listen request... >> >> FC: Request to create new listener. >> >>> vcl_session_app_add_segment_handler:855: vcl<24434:1>: mapped new segment >>> '24177-2' size 134217728 >> >> FC: This is probably the connects segment manager segment that was just >> created with the first segment in it. >> >>> vcl_session_connected_handler:505: vcl<24434:1>: session 1 [0x100000000] >>> connected! rx_fifo 0x224051c80, refcnt 1, tx_fifo 0x224051b80, refcnt 1 >> >> FC: Connect for previous listener (session 1) succeeded. >> >>> vcl_session_app_add_segment_handler:855: vcl<24434:1>: mapped new segment >>> '24177-3' size 134217728 >> >> FC: This is the new listener’s first segment manager segment. So session 2 >> has segment 24177-3 associated to it. >> >>> vcl_session_bound_handler:607: vcl<24434:1>: session 2 [0x0]: listen >>> succeeded! >>> vppcom_epoll_ctl:2658: vcl<24434:1>: EPOLL_CTL_ADD: vep_sh 16777216, sh >>> 16777218, events 0x1, data 0xffffffff! >> >> FC: Listen succeeded on session 2 and it was added to the vep group. >> >>> vcl_session_migrated_handler:674: vcl<24434:1>: Migrated 0x100000000 to >>> thread 2 0x200000000 >> >> FC: You got new data on the connected session (session 1) and the session >> was migrated to the rss selected thread in vpp. >> >>> new connecton >>> vppcom_session_connect:1742: vcl<24434:1>: session handle 16777218 >>> (STATE_CLOSED): connecting to peer IPv6 2001:5b0:ffff:700:b883:31f:29e:9886 >>> port 60725 proto UDP >> >> FC: Connecting session 2 (the latest listener) >> >>> vppcom_epoll_ctl:2696: vcl<24434:1>: EPOLL_CTL_MOD: vep_sh 16777216, sh >>> 16777218, events 0x2011, data 0x1000002! >> >>> vppcom_session_create:1279: vcl<24434:1>: created session 3 >>> vppcom_session_bind:1426: vcl<24434:1>: session 3 handle 16777219: binding >>> to local IPv6 address 2001:5b0:ffff:700:b883:31f:29e:9880 port 6677, proto >>> UDP >>> vppcom_session_listen:1458: vcl<24434:1>: session 16777219: sending vpp >>> listen request... >> >> FC: Trying to listen on a new session (session 3) >> >>> ssvm_delete_shm:205: unlink segment '24177-3': No such file or directory >>> (errno 2) >> >> FC: This is okay, I think, because vpp already deleted the shm segment (so >> there’s nothing left to delete). >> >> You might want to consider using memfd segments (although it involves a bit >> of configuration like here [1]). >> >> [1] https://wiki.fd.io/view/VPP/HostStack/LDP/iperf >> <https://wiki.fd.io/view/VPP/HostStack/LDP/iperf> >> >>> vcl_segment_detach:467: vcl<24434:1>: detached segment 3 handle 0 >>> vcl_session_app_del_segment_handler:863: vcl<24434:1>: Unmapped segment: 0 >> >> FC: Because session 2 stopped listening, the underlying segment manager (all >> listeners have a segment manager in vpp) was removed. VPP forced vcl to >> unmap the segment as well. >> >>> vcl_session_connected_handler:505: vcl<24434:1>: session 2 [0x100000000] >>> connected! rx_fifo 0x224051a80, refcnt 1, tx_fifo 0x224051980, refcnt 1 >>> vcl_session_app_add_segment_handler:855: vcl<24434:1>: mapped new segment >>> '24177-4' size 134217728 >>> vcl_session_bound_handler:607: vcl<24434:1>: session 3 [0x0]: listen >>> succeeded! >>> vppcom_epoll_ctl:2658: vcl<24434:1>: EPOLL_CTL_ADD: vep_sh 16777216, sh >>> 16777219, events 0x1, data 0xffffffff! >> >> FC: New listener (session 3) got new segment (and segment manager) and it >> was added to epoll group. >> >> Regards, >> Florin >> >>> >>> thanks, >>> -Raj >>> >>> >>> On Sat, May 16, 2020 at 2:23 PM Florin Coras <fcoras.li...@gmail.com >>> <mailto:fcoras.li...@gmail.com>> wrote: >>> Hi Raj, >>> >>> Assuming you are trying to open more than one connected udp session, does >>> this [1] solve the problem (note it's untested)? >>> >>> To reproduce legacy behavior, this allows you to listen on >>> VPPCOM_PROTO_UDPC but that is now converted by vcl into a udp listen that >>> propagates with a “connected” flag to vpp. That should result in a udp >>> listener that behaves like an “old” udpc listener. >>> >>> Regards, >>> Florin >>> >>> [1] https://gerrit.fd.io/r/c/vpp/+/27111 >>> <https://gerrit.fd.io/r/c/vpp/+/27111> >>> >>>> On May 16, 2020, at 10:56 AM, Florin Coras via lists.fd.io >>>> <http://lists.fd.io/> <fcoras.lists=gmail....@lists.fd.io >>>> <mailto:fcoras.lists=gmail....@lists.fd.io>> wrote: >>>> >>>> Hi Raj, >>>> >>>> Are you using master latest/20.05 rc1 or something older? The fact that >>>> you’re getting a -115 (EINPROGRESS) suggests you might’ve marked the >>>> connection as “non-blocking” although you created it as blocking. If >>>> that’s so, the return value is not an error. >>>> >>>> Also, how if vpp crashing? Are you by chance trying to open a lot of udp >>>> connections back to back? >>>> >>>> Regards, >>>> Florin >>>> >>>>> On May 16, 2020, at 10:23 AM, Raj Kumar <raj.gauta...@gmail.com >>>>> <mailto:raj.gauta...@gmail.com>> wrote: >>>>> >>>>> Hi Florin, >>>>> I tried to connect on receiving the first UDP packet . But, it did not >>>>> work. I am getting error -115 in the application and VPP is crashing. >>>>> >>>>> This is something I tried in the code (udp receiver) - >>>>> sockfd = vppcom_session_create(VPPCOM_PROTO_UDP, 0); >>>>> rv_vpp = vppcom_session_bind (sockfd, &endpt); >>>>> if (FD_ISSET(session_idx, &readfds)) >>>>> { >>>>> n = vppcom_session_recvfrom(sockfd, (char *)buffer, MAXLINE, 0, >>>>> &client); >>>>> if(first_pkt) >>>>> rv_vpp = vppcom_session_connect (sockfd, &client); >>>>> //Here getting rv_vpp as -115 >>>>> } >>>>> Please let me know if I am doing something wrong. >>>>> >>>>> Here are the traces - >>>>> >>>>> VCL<16083>: configured VCL debug level (2) from VCL_DEBUG! >>>>> VCL<16083>: using default heapsize 268435456 (0x10000000) >>>>> VCL<16083>: allocated VCL heap = 0x7fd255ed2010, size 268435456 >>>>> (0x10000000) >>>>> VCL<16083>: using default configuration. >>>>> vppcom_connect_to_vpp:487: vcl<16083:0>: app (udp6_rx) connecting to VPP >>>>> api (/vpe-api)... >>>>> vppcom_connect_to_vpp:502: vcl<16083:0>: app (udp6_rx) is connected to >>>>> VPP! >>>>> vppcom_app_create:1200: vcl<16083:0>: sending session enable >>>>> vppcom_app_create:1208: vcl<16083:0>: sending app attach >>>>> vppcom_app_create:1217: vcl<16083:0>: app_name 'udp6_rx', my_client_index >>>>> 0 (0x0) >>>>> >>>>> vppcom_connect_to_vpp:487: vcl<16083:1>: app (udp6_rx-wrk-1) connecting >>>>> to VPP api (/vpe-api)... >>>>> vppcom_connect_to_vpp:502: vcl<16083:1>: app (udp6_rx-wrk-1) is connected >>>>> to VPP! >>>>> vl_api_app_worker_add_del_reply_t_handler:235: vcl<94:-1>: worker 1 >>>>> vpp-worker 1 added >>>>> vcl_worker_register_with_vpp:262: vcl<16083:1>: added worker 1 >>>>> vppcom_session_create:1279: vcl<16083:1>: created session 0 >>>>> vppcom_session_bind:1426: vcl<16083:1>: session 0 handle 16777216: >>>>> binding to local IPv6 address 2001:5b0:ffff:700:b883:31f:29e:9880 port >>>>> 6677, proto UDP >>>>> vppcom_session_listen:1458: vcl<16083:1>: session 16777216: sending vpp >>>>> listen request... >>>>> vcl_session_bound_handler:607: vcl<16083:1>: session 0 [0x0]: listen >>>>> succeeded! >>>>> vppcom_session_connect:1742: vcl<16083:1>: session handle 16777216 >>>>> (STATE_CLOSED): connecting to peer IPv6 >>>>> 2001:5b0:ffff:700:b883:31f:29e:9886 port 51190 proto UDP >>>>> udpRxThread started!!! ... rx port = 6677vppcom_session_connect() >>>>> failed ... -115 >>>>> vcl_session_cleanup:1300: vcl<16083:1>: session 0 [0x0] closing >>>>> vcl_worker_cleanup_cb:190: vcl<94:-1>: cleaned up worker 1 >>>>> vl_client_disconnect:309: peer unresponsive, give up >>>>> >>>>> thanks, >>>>> -Raj >>>>> >>>>> >>>>> On Fri, May 15, 2020 at 8:10 PM Florin Coras <fcoras.li...@gmail.com >>>>> <mailto:fcoras.li...@gmail.com>> wrote: >>>>> Hi Raj, >>>>> >>>>> There are no explicit vcl apis that allow a udp listener to be switched >>>>> to connected mode. We might decide to do this at one point through a new >>>>> bind api (non-posix like) since we do support this for builtin >>>>> applications. >>>>> >>>>> However, you now have the option of connecting a bound session. That is, >>>>> on the first received packet on a udp listener, you can grab the peer’s >>>>> address and connect it. Iperf3 in udp mode, which is part of our make >>>>> test infra, does exactly that. Subsequently, it re-binds the port to >>>>> accept more connections. Would that work for you? >>>>> >>>>> Regards, >>>>> Florin >>>>> >>>>>> On May 15, 2020, at 4:06 PM, Raj Kumar <raj.gauta...@gmail.com >>>>>> <mailto:raj.gauta...@gmail.com>> wrote: >>>>>> >>>>>> Thanks! Florin, >>>>>> >>>>>> OK, I understood that I need to change my application to use UDP socket >>>>>> and then use vppcom_session_connect(). >>>>>> This is fine for the UDP client ( sender) . >>>>>> >>>>>> But ,in UDP Server ( receiver) , I am not sure how to use the >>>>>> vppcom_session_connect(). . >>>>>> I am using vppcom_session_listen() to listen on the connections and then >>>>>> calling vppcom_session_accept() to accept a new connection. >>>>>> >>>>>> With UDPC, I was able to utilize the RSS ( receiver side scaling) >>>>>> feature to move the received connections on the different cores /threads. >>>>>> >>>>>> Just want to confirm if I can achieve the same with UDP. >>>>>> >>>>>> I will change my application and will update you about the result. >>>>>> >>>>>> Thanks, >>>>>> -Raj >>>>>> >>>>>> >>>>>> On Fri, May 15, 2020 at 5:17 PM Florin Coras <fcoras.li...@gmail.com >>>>>> <mailto:fcoras.li...@gmail.com>> wrote: >>>>>> Hi Raj, >>>>>> >>>>>> We removed udpc transport in vpp. I’ll push a patch that removes it from >>>>>> vcl as well. >>>>>> >>>>>> Calling connect on a udp connection will give you connected semantics >>>>>> now. Let me know if that solves the issue for you. >>>>>> >>>>>> Regards, >>>>>> Florin >>>>>> >>>>>> >>>>>>> On May 15, 2020, at 12:15 PM, Raj Kumar <raj.gauta...@gmail.com >>>>>>> <mailto:raj.gauta...@gmail.com>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I am getting segmentation fault in VPP when using VCL VPPCOM_PROTO_UDPC >>>>>>> socket. This issue is observed with both UDP sender and UDP receiver >>>>>>> application. >>>>>>> >>>>>>> However, both UDP sender and receiver works fine with VPPCOM_PROTO_UDP. >>>>>>> >>>>>>> Here is the stack trace - >>>>>>> >>>>>>> (gdb) bt >>>>>>> #0 0x0000000000000000 in ?? () >>>>>>> #1 0x00007ffff775da59 in session_open_vc (app_wrk_index=1, >>>>>>> rmt=0x7fffb5e34cc0, opaque=0) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session.c:1217 >>>>>>> #2 0x00007ffff7779257 in session_mq_connect_handler >>>>>>> (data=0x7fffb676e7a8) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session_node.c:138 >>>>>>> #3 0x00007ffff7780f48 in session_event_dispatch_ctrl >>>>>>> (elt=0x7fffb643f51c, wrk=0x7fffb650a640) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session.h:262 >>>>>>> #4 session_queue_node_fn (vm=<optimized out>, node=<optimized out>, >>>>>>> frame=<optimized out>) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vnet/session/session_node.c:1409 >>>>>>> #5 0x00007ffff6b214c1 in dispatch_node (last_time_stamp=<optimized >>>>>>> out>, frame=0x0, dispatch_state=VLIB_NODE_STATE_POLLING, >>>>>>> type=VLIB_NODE_TYPE_INPUT, node=0x7fffb5a9a980, vm=0x7ffff6d7c200 >>>>>>> <vlib_global_main>) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:1235 >>>>>>> #6 vlib_main_or_worker_loop (is_main=1, vm=0x7ffff6d7c200 >>>>>>> <vlib_global_main>) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:1815 >>>>>>> #7 vlib_main_loop (vm=0x7ffff6d7c200 <vlib_global_main>) at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:1990 >>>>>>> #8 vlib_main (vm=<optimized out>, vm@entry=0x7ffff6d7c200 >>>>>>> <vlib_global_main>, input=input@entry=0x7fffb5e34fa0) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/main.c:2236 >>>>>>> #9 0x00007ffff6b61756 in thread0 (arg=140737334723072) at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/unix/main.c:658 >>>>>>> #10 0x00007ffff602fc0c in clib_calljmp () from >>>>>>> /lib64/libvppinfra.so.20.05 >>>>>>> #11 0x00007fffffffd1e0 in ?? () >>>>>>> #12 0x00007ffff6b627ed in vlib_unix_main (argc=<optimized out>, >>>>>>> argv=<optimized out>) >>>>>>> at >>>>>>> /usr/src/debug/vpp-20.05-rc0~748_g83d129837.x86_64/src/vlib/unix/main.c:730 >>>>>>> >>>>>>> Earlier , I tested this functionality with VPP 20.01 release with the >>>>>>> following patches and it worked perfectly. >>>>>>> https://gerrit.fd.io/r/c/vpp/+/24332 >>>>>>> <https://gerrit.fd.io/r/c/vpp/+/24332> >>>>>>> https://gerrit.fd.io/r/c/vpp/+/24334 >>>>>>> <https://gerrit.fd.io/r/c/vpp/+/24334> >>>>>>> https://gerrit.fd.io/r/c/vpp/+/24462 >>>>>>> <https://gerrit.fd.io/r/c/vpp/+/24462> >>>>>>> >>>>>>> Thanks, >>>>>>> -Raj >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16455): https://lists.fd.io/g/vpp-dev/message/16455 Mute This Topic: https://lists.fd.io/mt/74234856/21656 Mute #vpp-hoststack: https://lists.fd.io/mk?hashtag=vpp-hoststack&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
