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> 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 (#16432): https://lists.fd.io/g/vpp-dev/message/16432
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]
-=-=-=-=-=-=-=-=-=-=-=-
