Re: [vpp-dev] tls close from cli lead to assert error

2019-10-11 Thread Florin Coras
Hi, 

First of all, that’s just a test tool that forces closing of sessions by 
“faking” a transport close request. It can potentially lead to other issues if 
afterwards the app calls the wrong apis into the transport. It shouldn’t be 
used on production traffic. 

Having said that, your problem is probably solved by this [1]. That is, we know 
the thread for the session/ctx, so we can use the explicit api. 

Florin

[1] https://gerrit.fd.io/r/c/vpp/+/22674

> On Oct 11, 2019, at 6:24 AM, jiangxiaom...@outlook.com wrote:
> 
> code: g...@github.com:FDio/vpp.git   
> master : 1a41a35b27da6921d6d86a9f1ad5f1b46e1185f7
> 
> if i close tls session which is not in thread 0, VPP will assert error.
> Below is more Info:
> 
> 
> DBGvpp# sh session verbose
> 
> ConnectionState  Rx-f  
> Tx-f  
> 
> [0:0][CT:J] 0.0.0.0:5005->0.0.0.0:0   LISTEN 0 0  
>
> 
> [0:1][TLS] app_wrk 1 engine 2 tcp 0:20 0 
> 
> [0:2][T] 0.0.0.0:5005->0.0.0.0:0  LISTEN 0 0  
>
> 
> Thread 0: active sessions 3
> 
>  
> ConnectionState  Rx-f  
> Tx-f  
> 
> [1:0][T] 192.168.7.100:5005->192.168.7.101:54206  ESTABLISHED0 0  
>
> 
> [1:1][TLS] app_wrk 1 index 0 engine 2 tcp 1:0 state: 4  0 0   
>   
> 
> Thread 1: active sessions 2
> 
> DBGvpp# clear session thread 1 session 0
> 
> 0: /home/dev/code/vpp-master/src/plugins/tlsopenssl/tls_openssl.c:72 
> (openssl_ctx_get) assertion `! pool_is_free 
> (openssl_main.ctx_pool[vlib_get_thread_index ()], _e)' fails
> 
> Program received signal SIGABRT, Aborted.
> 
> 0x74a12337 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:55
> 
> 55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> 
> Missing separate debuginfos, use: debuginfo-install 
> libgcc-4.8.5-39.el7.x86_64 libuuid-2.23.2-61.el7.x86_64 
> numactl-libs-2.0.12-3.el7.x86_64
> 
> (gdb) bt
> 
> #0  0x74a12337 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:55
> 
> #1  0x74a13a28 in __GI_abort () at abort.c:90
> 
> #2  0x0040765a in os_panic () at 
> /home/dev/code/vpp-master/src/vpp/vnet/main.c:355
> 
> #3  0x7585ab29 in debugger () at 
> /home/dev/code/vpp-master/src/vppinfra/error.c:84
> 
> #4  0x7585aef8 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x7fffc9a96a40 "%s:%d (%s) assertion `%s' fails") at 
> /home/dev/code/vpp-master/src/vppinfra/error.c:143
> 
> #5  0x7fffc9a9110e in openssl_ctx_get (ctx_index=0) at 
> /home/dev/code/vpp-master/src/plugins/tlsopenssl/tls_openssl.c:71
> 
> #6  0x7747f20b in tls_ctx_get (ctx_handle=1073741824) at 
> /home/dev/code/vpp-master/src/vnet/tls/tls.c:298
> 
> #7  0x7747f522 in tls_session_disconnect_callback 
> (tls_session=0x7fffdaaa54c0) at 
> /home/dev/code/vpp-master/src/vnet/tls/tls.c:389
> 
> #8  0x77445b9a in app_worker_close_notify (app_wrk=0x7fffda55d280, 
> s=0x7fffdaaa54c0) at 
> /home/dev/code/vpp-master/src/vnet/session/application_worker.c:324
> 
> #9  0x7744a45b in clear_session (s=0x7fffdaaa54c0) at 
> /home/dev/code/vpp-master/src/vnet/session/session_cli.c:594
> 
> #10 0x7744a681 in clear_session_command_fn (vm=0x766b3d80 
> , input=0x7fffda82af00, cmd=0x7fffda3ff2c0) at 
> /home/dev/code/vpp-master/src/vnet/session/session_cli.c:635
> 
> #11 0x763c5105 in vlib_cli_dispatch_sub_commands (vm=0x766b3d80 
> , cm=0x766b3fb0 , 
> input=0x7fffda82af00, parent_command_index=59) at 
> /home/dev/code/vpp-master/src/vlib/cli.c:645
> 
> #12 0x763c4f9a in vlib_cli_dispatch_sub_commands (vm=0x766b3d80 
> , cm=0x766b3fb0 , 
> input=0x7fffda82af00, parent_command_index=0) at 
> /home/dev/code/vpp-master/src/vlib/cli.c:606
> 
> #13 0x763c5530 in vlib_cli_input (vm=0x766b3d80 
> , input=0x7fffda82af00, function=0x7646b44c 
> , function_arg=0) at 
> /home/dev/code/vpp-master/src/vlib/cli.c:746
> 
> #14 0x76471626 in unix_cli_process_input (cm=0x766b4720 
> , cli_file_index=0) at 
> /home/dev/code/vpp-master/src/vlib/unix/cli.c:2572
> 
> #15 0x76472198 in unix_cli_process (vm=0x766b3d80 
> , rt=0x7fffda7ea000, f=0x0) at 
> /home/dev/code/vpp-master/src/vlib/unix/cli.c:2688
> 
> #16 0x76412884 in vlib_process_bootstrap (_a=140736833976688) at 
> /home/dev/code/vpp-master/src/vlib/main.c:1472
> 
> #17 0x7587b9a0 in clib_calljmp () from 
> /home/dev/code/vpp-master/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.20.01
> 
> #18 0x7fffd8fef940 in ?? ()
> 
> #19 0x7641298c in vlib_process_startup (vm=0x766b3d80 
> , p=0x267, f=0x0) at 
> /home/dev/code/vpp-master/src/vlib/main.c:1494
> 
> The reason is that:
> tls_ctx_t struct is create 

Re: [vpp-dev] VPP Hoststack CPS

2019-10-10 Thread Florin Coras
Ni Nataraj, 

I haven’t tested this recently but we’re planning on adding some tcp + vcl 
related performance testing to csit.

Regards, 
Florin

> On Oct 10, 2019, at 6:30 PM, Nataraj Batchu  wrote:
> 
> Hi Florin:
> 
> Thanks for the quick reply. By any chance, do you have latest CPS numbers? Or 
> any document to look at that you/your team published?  -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14156): https://lists.fd.io/g/vpp-dev/message/14156
> Mute This Topic: https://lists.fd.io/mt/34465863/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP Hoststack CPS

2019-10-09 Thread Florin Coras
Hi Nataraj, 

The test was done with the builtin echo applications over a 40Gbps link with no 
latency and it measured CPS as number of TCP handshakes per second. Also, note 
that’s a pretty old presentation. 

Florin

> On Oct 9, 2019, at 10:30 AM, Nataraj Batchu  wrote:
> 
> Hi,
> 
> In the slide deck at https://wiki.fd.io/images/b/b4/Vpp-hoststack-kc.pdf 
>  I see that with VPP 
> Hoststack 200k CPS is achieved. Have few questions:
> 
> a. Are the sessions originated from App linked with VCL? 
> b. Is the TCP connection over the network or on local host?
> b. Non-blocking connect fixes are available only recently. Were the results 
> with blocking connect()? 
> 
> Thanks in advance.
> 
> -Nataraj -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14153): https://lists.fd.io/g/vpp-dev/message/14153
> Mute This Topic: https://lists.fd.io/mt/34465863/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#14154): https://lists.fd.io/g/vpp-dev/message/14154
Mute This Topic: https://lists.fd.io/mt/34465863/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_node_add_next usage #vpp

2019-10-03 Thread Florin Coras
Hi Ranadip, 

Yes, the session layer updates all vms when it adds a new arc from 
session_queue_node to whatever the transport wants to use for output. I don’t 
remember now why we did things that way, but it may be that it’s not needed 
anymore. 

Florin

> On Oct 2, 2019, at 9:23 PM, Ranadip Das  wrote:
> 
> The session_register_transport() has the foreach code.
> 
>  1381  /* *INDENT-OFF* */
>  <> 1382  if (output_node != ~0)
>  <> 1383  {
>  <> 1384  foreach_vlib_main 
> 
>  (({
>  <> 1385  next_index = vlib_node_add_next 
> 
>  (this_vlib_main,
>  <> 1386  session_queue_node 
> .index,
>  <> 1387  output_node);
>  <> 1388  }));
>  <> 1389  }
>  <> 1390  /* *INDENT-ON* */
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14103): https://lists.fd.io/g/vpp-dev/message/14103
> Mute This Topic: https://lists.fd.io/mt/34376308/675152
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] UDP packet sending using sendto()

2019-09-25 Thread Florin Coras
Hi Nataraj, 

It’s not possible with VCL at this point but it’s possible with builtin 
applications. It’s just a matter of extending the connect api to support this. 

Florin

> On Sep 25, 2019, at 6:16 PM, Nataraj Batchu  wrote:
> 
> Hi,
> 
> Today with VPP we cannot give endpoint info in sendto() call. We have to do a 
> connect(udp_sock, endpoint_info) first and then invoke sendto(). This works. 
> But the question is how can I influence the source port of these packets?
> 
> Thanks,
> -Nataraj -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14057): https://lists.fd.io/g/vpp-dev/message/14057
> Mute This Topic: https://lists.fd.io/mt/34294099/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#14058): https://lists.fd.io/g/vpp-dev/message/14058
Mute This Topic: https://lists.fd.io/mt/34294099/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] VLC: tls in open tcp session

2019-09-16 Thread Florin Coras
Hi Max, 

No, it’s not possible. 

Florin

> On Sep 16, 2019, at 1:35 AM, Max A. via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Is it possible to switch to using TLS in an already open TCP session using 
> VCL?
> 
> Thanks. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13987): https://lists.fd.io/g/vpp-dev/message/13987
> Mute This Topic: https://lists.fd.io/mt/34162392/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP API client with no rx pthread

2019-09-11 Thread Florin Coras
Hi Satya, 

Probably you can just replicate what the api rx-thread is doing, i.e., 
rx_thread_fn. In particular, take a look at vl_msg_api_queue_handler. 

Florin

> On Sep 11, 2019, at 3:26 AM, Satya Murthy  wrote:
> 
> Hi ,
> 
> We are trying to develop a VPP API client which needs synchronous reply 
> handling.
> Hence, we were thinking of NOT having a separate pthread for receiving the 
> response from VPP.
> We are planning to use no_rx_pthread version of connect api.
> 
> Is there any example code to receive and handle the response synchronously.
> I see all the examples are using separate pthread for receiving.
> 
> Any input on this will be of great help.
> 
> -- 
> Thanks & Regards,
> Murthy -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13952): https://lists.fd.io/g/vpp-dev/message/13952
> Mute This Topic: https://lists.fd.io/mt/34101834/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13956): https://lists.fd.io/g/vpp-dev/message/13956
Mute This Topic: https://lists.fd.io/mt/34101834/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] vppcom_session_connect blocking or non blocking

2019-09-04 Thread Florin Coras
Hi Max, 

Here’s the patch that allows non-blocking connects [1]. 

Florin

[1] https://gerrit.fd.io/r/c/vpp/+/21610 <https://gerrit.fd.io/r/c/vpp/+/21610>

> On Aug 15, 2019, at 7:41 AM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> Hi Max,
> 
> Not at this time. It should be possible with a few changes for nonblocking 
> sessions. I’ll add it to my list, in case nobody else beats me to it. 
> 
> Florin
> 
>> On Aug 15, 2019, at 2:47 AM, Max A. via Lists.Fd.Io 
>>  wrote:
>> 
>> Hello,
>> 
>> Can vppcom_session_connect() function run in non-blocking mode? I see that 
>> there is a wait for the connection result in the 
>> vppcom_wait_for_session_state_change function.  Is it possible to get the 
>> result of the connection using vppcom_epoll_wait?
>> 
>> Thanks.
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#13745): https://lists.fd.io/g/vpp-dev/message/13745
>> Mute This Topic: https://lists.fd.io/mt/32885087/675152
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13747): https://lists.fd.io/g/vpp-dev/message/13747
> Mute This Topic: https://lists.fd.io/mt/32885087/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP 19.08 release is available!

2019-08-22 Thread Florin Coras
Congrats to the entire community and thanks Andrew!

Cheers,
Florin

> On Aug 21, 2019, at 1:57 PM, Andrew Yourtchenko  wrote:
> 
> Hi all,
> 
> the VPP release 19.08 artifacts are available on packagecloud release
> repositories.
> 
> I have tested the installation on ubuntu and centos.
> 
> Many thanks to everyone involved into making it happen!
> 
> Special thanks to Vanessa Valderrama for the help today.
> 
> --a
> 
> 
> p.s. stable/1908 branch is re-opened for the fixes slated for .1
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13804): https://lists.fd.io/g/vpp-dev/message/13804
> Mute This Topic: https://lists.fd.io/mt/32983052/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13816): https://lists.fd.io/g/vpp-dev/message/13816
Mute This Topic: https://lists.fd.io/mt/32983052/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] ValueError: Fieldname 'async' is a python keyword and is not accessible via the python API

2019-08-21 Thread Florin Coras

> On Aug 21, 2019, at 8:32 AM, Damjan Marion  wrote:
> 
>> 
>> On 21 Aug 2019, at 17:15, Florin Coras > <mailto:fcoras.li...@gmail.com>> wrote:
>> 
>> Interesting. Want to push a patch to change async_enable or something like 
>> that here [1]? Or I can do that. 
>> 
>> Florin
>> 
>> [1] 
>> https://git.fd.io/vpp/diff/src/plugins/tlsopenssl/tls_openssl.api?id=be4d1aa 
>> <https://git.fd.io/vpp/diff/src/plugins/tlsopenssl/tls_openssl.api?id=be4d1aa>
>> 
>>> On Aug 21, 2019, at 7:41 AM, Damjan Marion via Lists.Fd.Io 
>>> mailto:dmarion=me@lists.fd.io>> wrote:
>>> 
>>> 
>>> May be due to the fact that I use newer ubuntu version, but i’m not able to 
>>> build VPP on master.
>>> 
>>> This is error message I get:
>>> 
>>> [1283/1678] Generating API header 
>>> /home/damarion/cisco/vpp8/bui...build-vpp_debug-native/vpp/plugins/tlsopenssl/tls_openssl.api.h
>>> FAILED: plugins/tlsopenssl/tls_openssl.api.h
>>> cd 
>>> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl
>>>  && mkdir -p 
>>> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl
>>>  && /home/damarion/cisco/vpp8/src/tools/vppapigen/vppapigen --includedir 
>>> /home/damarion/cisco/vpp8/src --input 
>>> /home/damarion/cisco/vpp8/src/plugins/tlsopenssl/tls_openssl.api --output 
>>> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl/tls_openssl.api.h
>>> ValueError: Fieldname 'async' is a python keyword and is not accessible via 
>>> the python API.
>>> 
>>> 
>>> And looks like reverting [1] helps….
>>> 
>>> [1] https://git.fd.io/vpp/commit/?id=be4d1aa 
>>> <https://git.fd.io/vpp/commit/?id=be4d1aa>
>>> 
> 
> It sounds to me like right solution to the problem is to avoid python 
> keyword-related constrains in API msg fields.
> 
> Next time they may add new keyword and break existing API definitions….

Agreed. I suspect the issue is that we pass those fields as named params in 
python apis, but Ole should know the actual answer. 

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

View/Reply Online (#13801): https://lists.fd.io/g/vpp-dev/message/13801
Mute This Topic: https://lists.fd.io/mt/32978936/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] ValueError: Fieldname 'async' is a python keyword and is not accessible via the python API

2019-08-21 Thread Florin Coras
Interesting. Want to push a patch to change async_enable or something like that 
here [1]? Or I can do that. 

Florin

[1] 
https://git.fd.io/vpp/diff/src/plugins/tlsopenssl/tls_openssl.api?id=be4d1aa 


> On Aug 21, 2019, at 7:41 AM, Damjan Marion via Lists.Fd.Io 
>  wrote:
> 
> 
> May be due to the fact that I use newer ubuntu version, but i’m not able to 
> build VPP on master.
> 
> This is error message I get:
> 
> [1283/1678] Generating API header 
> /home/damarion/cisco/vpp8/bui...build-vpp_debug-native/vpp/plugins/tlsopenssl/tls_openssl.api.h
> FAILED: plugins/tlsopenssl/tls_openssl.api.h
> cd 
> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl
>  && mkdir -p 
> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl
>  && /home/damarion/cisco/vpp8/src/tools/vppapigen/vppapigen --includedir 
> /home/damarion/cisco/vpp8/src --input 
> /home/damarion/cisco/vpp8/src/plugins/tlsopenssl/tls_openssl.api --output 
> /home/damarion/cisco/vpp8/build-root/build-vpp_debug-native/vpp/plugins/tlsopenssl/tls_openssl.api.h
> ValueError: Fieldname 'async' is a python keyword and is not accessible via 
> the python API.
> 
> 
> And looks like reverting [1] helps….
> 
> [1] https://git.fd.io/vpp/commit/?id=be4d1aa 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13798): https://lists.fd.io/g/vpp-dev/message/13798
> Mute This Topic: https://lists.fd.io/mt/32978936/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13799): https://lists.fd.io/g/vpp-dev/message/13799
Mute This Topic: https://lists.fd.io/mt/32978936/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] vppcom_session_connect blocking or non blocking

2019-08-15 Thread Florin Coras
Hi Max,

Not at this time. It should be possible with a few changes for nonblocking 
sessions. I’ll add it to my list, in case nobody else beats me to it. 

Florin

> On Aug 15, 2019, at 2:47 AM, Max A. via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Can vppcom_session_connect() function run in non-blocking mode? I see that 
> there is a wait for the connection result in the 
> vppcom_wait_for_session_state_change function.  Is it possible to get the 
> result of the connection using vppcom_epoll_wait?
> 
> Thanks.
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13745): https://lists.fd.io/g/vpp-dev/message/13745
> Mute This Topic: https://lists.fd.io/mt/32885087/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13747): https://lists.fd.io/g/vpp-dev/message/13747
Mute This Topic: https://lists.fd.io/mt/32885087/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] Envoy transport socket support for vpp.

2019-08-06 Thread Florin Coras
Hi Rupesh, 

CC’ing Stephen and Ping who are working on this. 

Florin

> On Aug 5, 2019, at 4:36 AM, Rupesh Raghuvaran  
> wrote:
> 
> Hi,
> 
> I would like to know the current state of the support for envoy over vpp host 
> stack. Is there any open source transport socket support for vpp available 
> for envoy.
> 
> Thanks
> Rupesh  -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13661): https://lists.fd.io/g/vpp-dev/message/13661
> Mute This Topic: https://lists.fd.io/mt/32724370/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13674): https://lists.fd.io/g/vpp-dev/message/13674
Mute This Topic: https://lists.fd.io/mt/32724370/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] Transport endpoint extraction while using vnet_connect_uri

2019-08-01 Thread Florin Coras
Hi Praveen, 

That’s just master branch :-)

Florin

> On Aug 1, 2019, at 2:03 PM, Praveen Kariyanahalli  
> wrote:
> 
> I dont see that tag 1908. How do I get that code? 
> 
> Thanks in advance
> Praveen
> ᐧ
> 
> On Wed, Jul 31, 2019 at 10:18 PM Florin Coras  <mailto:fcoras.li...@gmail.com>> wrote:
> Hi Praveen, 
> 
> In 19.08 you can grab the local and remote endpoints with 
> session_get_endpoint. We didn’t have these in 19.04.
> 
> Florin
> 
>> On Jul 31, 2019, at 7:18 PM, Praveen Kariyanahalli > <mailto:praveen.ha...@gmail.com>> wrote:
>> 
>> I wrote an client app to connect to remote tls_server using 
>> vnet_connect_uri. 
>> 
>> Post connect, how do I extract the transport end points (local bind ip, 
>> port, rmt ip, rmt port). I am using 1904 version of the code. 
>> 
>> ct = transport_get_connection (ecm->transport_proto, index, 
>> thread_index);
>> 
>> Is not helping ... returns 0.
>> 
>> Context neither under TLS proto nor under TCP
>> 
>> What am I missing?
>> 
>> Thanks in advance
>> Praveen
>> 
>> 
>> ᐧ
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#13636): https://lists.fd.io/g/vpp-dev/message/13636 
>> <https://lists.fd.io/g/vpp-dev/message/13636>
>> Mute This Topic: https://lists.fd.io/mt/32674842/675152 
>> <https://lists.fd.io/mt/32674842/675152>
>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

View/Reply Online (#13648): https://lists.fd.io/g/vpp-dev/message/13648
Mute This Topic: https://lists.fd.io/mt/32674842/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] Transport endpoint extraction while using vnet_connect_uri

2019-07-31 Thread Florin Coras
Hi Praveen, 

In 19.08 you can grab the local and remote endpoints with session_get_endpoint. 
We didn’t have these in 19.04.

Florin

> On Jul 31, 2019, at 7:18 PM, Praveen Kariyanahalli  
> wrote:
> 
> I wrote an client app to connect to remote tls_server using vnet_connect_uri. 
> 
> Post connect, how do I extract the transport end points (local bind ip, port, 
> rmt ip, rmt port). I am using 1904 version of the code. 
> 
> ct = transport_get_connection (ecm->transport_proto, index, 
> thread_index);
> 
> Is not helping ... returns 0.
> 
> Context neither under TLS proto nor under TCP
> 
> What am I missing?
> 
> Thanks in advance
> Praveen
> 
> 
> ᐧ
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13636): https://lists.fd.io/g/vpp-dev/message/13636
> Mute This Topic: https://lists.fd.io/mt/32674842/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13638): https://lists.fd.io/g/vpp-dev/message/13638
Mute This Topic: https://lists.fd.io/mt/32674842/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] [dmm-dev] FD.io - Gerrit 2.16 Changes

2019-07-30 Thread Florin Coras
Apologies, seems today is not my day with links. 

Florin

[1] https://github.com/openstack-infra/git-review/tree/master/git_review 
<https://github.com/openstack-infra/git-review/tree/master/git_review>

> On Jul 30, 2019, at 1:51 PM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> Pushed send too soon 
> 
> Florin
> 
> [1] /usr/lib/python3/dist-packages/git_review/cmd.py
> 
>> On Jul 30, 2019, at 1:49 PM, Florin Coras via Lists.Fd.Io 
>> > <mailto:fcoras.lists=gmail@lists.fd.io>> wrote:
>> 
>> It seems that this [1] supports the new workflows. Just overwriting 
>> /usr/lib/python3/dist-packages/git_review/cmd.py seems to do the trick. 
>> 
>> I’m sure there must be a cleaner way … 
>> 
>> Florin
>> 
>>> On Jul 30, 2019, at 1:20 PM, Vanessa Valderrama 
>>> mailto:vvalderr...@linuxfoundation.org>> 
>>> wrote:
>>> 
>>> Changes that will happen with Gerrit:
>>> 
>>> 1) The 'New UI' for Gerrit will become the default UI
>>> 
>>> 2) The Draft work flow is removed and replaced with 'Work in Progress'
>>> aka 'WIP' and 'Private' workflows. Unfortunately git-review does not
>>> support either of these workflows directly. Utilizing them means either
>>> pushing your changes the manual way for either system or pushing them up
>>> with git-review and then marking the change via the UI into either of
>>> the workflows.
>>> 
>>> 
>>> To push a private change you may do so as follows:
>>> git push origin HEAD:refs/for/master%private
>>> 
>>> To pull it out of private you may do so as follows:
>>> git push origin HEAD:refs/for/master%remove-private
>>> 
>>> To push a WIP you may do so as follows:
>>> git push origin HEAD:refs/for/master%wip
>>> 
>>> To mark it ready for review you may do so as follows:
>>> git push origin HEAD:refs/for/master%ready
>>> 
>>> Once a change is in either private or WIP state it does not switch the
>>> change to a ready state until the current state has been removed.
>>> 
>>> In both cases, the state can be set via the UI by selecting the tripple
>>> dot menu option on the change and selecting the appropriate option.
>>> 
>>> To remove WIP state press the 'START REVIEW' button. To remove the
>>> private state you must do so via the menu.
>>> 
>>> NOTE: We are not moving to Gerrit 3 at this time. That is on the road
>>> map but we need to come to the latest 2.x as we have to do various
>>> migrations that are only available at the 2.16 level before we can move
>>> to Gerrit 3.
>>> 
>>> Thank you,
>>> Vanessa
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#61): https://lists.fd.io/g/dmm-dev/message/61 
>>> <https://lists.fd.io/g/dmm-dev/message/61>
>>> Mute This Topic: https://lists.fd.io/mt/32658314/675152 
>>> <https://lists.fd.io/mt/32658314/675152>
>>> Group Owner: dmm-dev+ow...@lists.fd.io <mailto:dmm-dev+ow...@lists.fd.io>
>>> Unsubscribe: https://lists.fd.io/g/dmm-dev/unsub 
>>> <https://lists.fd.io/g/dmm-dev/unsub>  [fcoras.li...@gmail.com 
>>> <mailto:fcoras.li...@gmail.com>]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#13624): https://lists.fd.io/g/vpp-dev/message/13624 
>> <https://lists.fd.io/g/vpp-dev/message/13624>
>> Mute This Topic: https://lists.fd.io/mt/32658598/675152 
>> <https://lists.fd.io/mt/32658598/675152>
>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13625): https://lists.fd.io/g/vpp-dev/message/13625
> Mute This Topic: https://lists.fd.io/mt/32658616/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13626): https://lists.fd.io/g/vpp-dev/message/13626
Mute This Topic: https://lists.fd.io/mt/32658627/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] [dmm-dev] FD.io - Gerrit 2.16 Changes

2019-07-30 Thread Florin Coras
Pushed send too soon 

Florin

[1] /usr/lib/python3/dist-packages/git_review/cmd.py

> On Jul 30, 2019, at 1:49 PM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> It seems that this [1] supports the new workflows. Just overwriting 
> /usr/lib/python3/dist-packages/git_review/cmd.py seems to do the trick. 
> 
> I’m sure there must be a cleaner way … 
> 
> Florin
> 
>> On Jul 30, 2019, at 1:20 PM, Vanessa Valderrama 
>> mailto:vvalderr...@linuxfoundation.org>> 
>> wrote:
>> 
>> Changes that will happen with Gerrit:
>> 
>> 1) The 'New UI' for Gerrit will become the default UI
>> 
>> 2) The Draft work flow is removed and replaced with 'Work in Progress'
>> aka 'WIP' and 'Private' workflows. Unfortunately git-review does not
>> support either of these workflows directly. Utilizing them means either
>> pushing your changes the manual way for either system or pushing them up
>> with git-review and then marking the change via the UI into either of
>> the workflows.
>> 
>> 
>> To push a private change you may do so as follows:
>> git push origin HEAD:refs/for/master%private
>> 
>> To pull it out of private you may do so as follows:
>> git push origin HEAD:refs/for/master%remove-private
>> 
>> To push a WIP you may do so as follows:
>> git push origin HEAD:refs/for/master%wip
>> 
>> To mark it ready for review you may do so as follows:
>> git push origin HEAD:refs/for/master%ready
>> 
>> Once a change is in either private or WIP state it does not switch the
>> change to a ready state until the current state has been removed.
>> 
>> In both cases, the state can be set via the UI by selecting the tripple
>> dot menu option on the change and selecting the appropriate option.
>> 
>> To remove WIP state press the 'START REVIEW' button. To remove the
>> private state you must do so via the menu.
>> 
>> NOTE: We are not moving to Gerrit 3 at this time. That is on the road
>> map but we need to come to the latest 2.x as we have to do various
>> migrations that are only available at the 2.16 level before we can move
>> to Gerrit 3.
>> 
>> Thank you,
>> Vanessa
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#61): https://lists.fd.io/g/dmm-dev/message/61 
>> <https://lists.fd.io/g/dmm-dev/message/61>
>> Mute This Topic: https://lists.fd.io/mt/32658314/675152 
>> <https://lists.fd.io/mt/32658314/675152>
>> Group Owner: dmm-dev+ow...@lists.fd.io <mailto:dmm-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/dmm-dev/unsub 
>> <https://lists.fd.io/g/dmm-dev/unsub>  [fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13624): https://lists.fd.io/g/vpp-dev/message/13624
> Mute This Topic: https://lists.fd.io/mt/32658598/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13625): https://lists.fd.io/g/vpp-dev/message/13625
Mute This Topic: https://lists.fd.io/mt/32658616/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] [dmm-dev] FD.io - Gerrit 2.16 Changes

2019-07-30 Thread Florin Coras
It seems that this [1] supports the new workflows. Just overwriting 
/usr/lib/python3/dist-packages/git_review/cmd.py seems to do the trick. 

I’m sure there must be a cleaner way … 

Florin

> On Jul 30, 2019, at 1:20 PM, Vanessa Valderrama 
>  wrote:
> 
> Changes that will happen with Gerrit:
> 
> 1) The 'New UI' for Gerrit will become the default UI
> 
> 2) The Draft work flow is removed and replaced with 'Work in Progress'
> aka 'WIP' and 'Private' workflows. Unfortunately git-review does not
> support either of these workflows directly. Utilizing them means either
> pushing your changes the manual way for either system or pushing them up
> with git-review and then marking the change via the UI into either of
> the workflows.
> 
> 
> To push a private change you may do so as follows:
> git push origin HEAD:refs/for/master%private
> 
> To pull it out of private you may do so as follows:
> git push origin HEAD:refs/for/master%remove-private
> 
> To push a WIP you may do so as follows:
> git push origin HEAD:refs/for/master%wip
> 
> To mark it ready for review you may do so as follows:
> git push origin HEAD:refs/for/master%ready
> 
> Once a change is in either private or WIP state it does not switch the
> change to a ready state until the current state has been removed.
> 
> In both cases, the state can be set via the UI by selecting the tripple
> dot menu option on the change and selecting the appropriate option.
> 
> To remove WIP state press the 'START REVIEW' button. To remove the
> private state you must do so via the menu.
> 
> NOTE: We are not moving to Gerrit 3 at this time. That is on the road
> map but we need to come to the latest 2.x as we have to do various
> migrations that are only available at the 2.16 level before we can move
> to Gerrit 3.
> 
> Thank you,
> Vanessa
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#61): https://lists.fd.io/g/dmm-dev/message/61
> Mute This Topic: https://lists.fd.io/mt/32658314/675152
> Group Owner: dmm-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/dmm-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13624): https://lists.fd.io/g/vpp-dev/message/13624
Mute This Topic: https://lists.fd.io/mt/32658598/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] [tsc] FD.io Maintenance: 2019-07-30 @ 1700 UTC (10:00am PDT) - 2100 UTC (2:00pm PDT)

2019-07-30 Thread Florin Coras
I definitely like the new UI. But now I’m getting:

"! [remote rejected] HEAD -> refs/drafts/master (draft workflow is 
disabled)”

Did something change?

Thanks, 
Florin

> On Jul 30, 2019, at 11:57 AM, Vanessa Valderrama 
>  wrote:
> 
> Maintenance is complete. All systems are now available. We'll be doing some 
> additional testing and monitoring throughout the day. If you experience any 
> issues please open a ticket at support.linuxfoundation.org.
> 
> Thank you,
> Vanessa
> 
> On 07/30/2019 12:01 PM, Vanessa Valderrama wrote:
>> Starting maintenance
>> 
>> 
>> On 07/30/2019 11:02 AM, Vanessa Valderrama wrote:
>>> Jenkins has been placed in shutdown mode for maintenance
>>> 
>>> 
>>> 
>>> 
>>> On 07/29/2019 10:29 AM, Vanessa Valderrama wrote:
 Maintenance reminder
 
 
 On 07/25/2019 04:09 PM, Vanessa Valderrama wrote:
> 
> What:
> 
> FD.io system maintenance
> 
> Jenkins
> OS updates
> Upgrade from 2.164.3 to 2.176.2
> https://jenkins.io/changelog-stable/ 
> 
> Update plug-ins
> Memory upgrade
> Nexus
> OS updates
> Gerrit
> OS updates
> Upgrade from 2.14.6 to 2.16
> https://www.gerritcodereview.com/2.16.html 
> 
> JIRA
> OS updates
> Sonar
> OS updates
> OpenGrok OS updates
> When:
> 
> 2019-07-30 @ 1700 UTC (10:00am PDT) - 2100 UTC (2:00pm PDT)
> 
> Impact:
> 
> The maintenance will require a reboot of each FD.io system. Jenkins will 
> be placed in shutdown mode at 1600 UTC.  Please let us know if there are 
> any jobs that cannot be aborted.  The following systems will be impacted:
> 
> Jenkins production
> Jenkins sandbox
> Nexus
> Gerrit
> JIRA
> Sonar
> OpenGrok
> 
 
>>> 
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#1062): https://lists.fd.io/g/tsc/message/1062
> Mute This Topic: https://lists.fd.io/mt/32603363/675152
> Group Owner: tsc+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/tsc/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13621): https://lists.fd.io/g/vpp-dev/message/13621
Mute This Topic: https://lists.fd.io/mt/32657900/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] TCP host stack & small size fifo

2019-07-28 Thread Florin Coras
Hi Max,

Inline.

> On Jul 28, 2019, at 10:47 AM, Max A.  wrote:
> 
> Hi Florin,
> 
> I simplified the application. It sends the request and reads all the data 
> from the server using the 8 KB buffer. The fifo size is set to 8 KB. In the 
> attached dump [1] you can see that in packet number 14 there will be an 
> overflow of the size of the tcp window.

Looks much better. I suspect that the issue with packet 14 is the fact that vpp 
accepts the session and notifies vcl of it, but vcl needs a bit of time to 
initialize its state and therefore won’t manage to read any data prior to the 
fifo being filled. 

> My application reports the size of the received block. If the tcp window size 
> is full, the application receives 7240 bytes from vpp. Next, the application 
> receives data no larger than 6 KB, and the problem does not occur. At what 
> point in time does vpp decide that the buffer is full, before I get the data 
> from the read function?

TCP in vpp processes bursts of packets (up to 256). If a packet in a burst is 
accepted, tcp enqueues its data in the associated session's rx fifo, shared 
with the app, and it sends a notification for that session at the end of the 
burst only if the fifo does not already have one. From what you’re seeing, not 
all 7240B come in a burst, so vcl gets a notification before the rx fifo fills.
 
> There is also a slightly different question. Is the fifo allocated for the 
> all lifetime of the session?

Short answer yes. It’s just a chunk of memory shared by the session layer with 
vcl.

Longer answer is that the fifo's data portion (where connection data is stored) 
can be grown, so more data could be enqueued. But fifo growth is not managed 
transparently by the session layer (i.e., no auto tuning), and at this time, 
external applications (like vcl) can’t control the fifo size. 

Florin

> 
> Thanks.
> 
> [1] https://drive.google.com/open?id=1Q__5UgnBAKoRGfaGaqIxAVNWqoSCzIPZ 
>  
> 
> -- 
> Max A.

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

View/Reply Online (#13598): https://lists.fd.io/g/vpp-dev/message/13598
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

2019-07-26 Thread Florin Coras
Hi Max, 

By the looks of it, the result is different, although not perfect. That is, you 
can now see multiple packets (more than the 14k) exchanged before window goes 
to zero. 

How are you reading the data in vcl, i.e., how large is your read buffer? I 
hope it’s at least around 8-14kB. 

Also, if the linux scheduler de-schedules vcl, from time to time data will 
accumulate and the rx fifo will fill. You can solve that by changing the 
priority of your app or by trying this out with a builtin application.

Florin

> On Jul 26, 2019, at 2:14 AM, Max A.  wrote:
> 
> Hi Florin,
> 
> 
> 
> That’s an important difference because in case of the proxy, you cannot 
> dequeue the data from the fifo before you send it to the actual destination 
> and it gets acknowledged. That means, you need to wait at least one rtt (to 
> the final destination) before you can make space in the fifo. If the final 
> destination consuming the data is slower than the sender, you have an even 
> bigger problem.
> 
> Try doing a simple wget client, builtin or with vcl, and you’ll note that 
> data should be dequeued much faster than in the proxy case.
> 
> I made a simple get application and got the exact same result [1]. If 
> necessary, I can give you the source of the application, it is built under 
> vcl and under linux.
> 
> Thanks.
> 
> [1] https://drive.google.com/open?id=1pkymyLtpaiEwYstcdgb-pzHqWEuTDzCF
> -- 
> Max A.

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

View/Reply Online (#13593): https://lists.fd.io/g/vpp-dev/message/13593
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

2019-07-25 Thread Florin Coras
Hi Max, 


> On Jul 25, 2019, at 6:09 AM, Max A.  wrote:
> 
> Hi Florin,
> 
> I tried to increase the buffer size to 128k. The problem still arises, only 
> less often [1]. The smaller the buffer, the more often the problem occurs.

Yup, for maximum throughput, fifo size needs to be large enough to buffer all 
the data from the sender while it delivers it to the consumer. If the consumer 
is slower than the producer, you’ll end up with an ever growing fifo. If 
there’s no difference, the fifo size depends on 1) producer/sender speed and 2) 
how fast you can get the data delivered from proxy to the consumer. Typically, 
the main component of the delivery time is the rtt to the consumer. 

Florin

> 
> Thanks.
> 
> [1] https://drive.google.com/open?id=1KVSzHhPscpSNkdLN0k2gddPJwccpguoo 
>  
> 
> -- 
> Max A.

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

View/Reply Online (#13583): https://lists.fd.io/g/vpp-dev/message/13583
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

2019-07-25 Thread Florin Coras
Hi Max, 

> On Jul 25, 2019, at 5:51 AM, Max A.  wrote:
> 
> Hi Florin,
> 
> 
> As explained above, as long as the sender is faster, this will happen. Still, 
> out of curiosity, can you try this [1] to see if it changes linux’s behavior 
> in any way? Although, I suspect the linux’s window probe timer, after a zero 
> window, is not smaller than min rto (which is the 200 ms you’re seeing). 
> 
> [1] https://gerrit.fd.io/r/c/20830/ 
> 
> Unfortunately, nothing has changed [1].

Oh well, zero window probe timer is the same 200ms. 

> 
> Therefore, is the data read by the application much faster or is the 
> advertised rcv window unrelated to the amount of data buffered? Obviously, if 
> the latter, the actual buffer is larger than what you’ve configured. Also, 
> does mtcp act as proxy in this case as well? 
> 
> The mtcp application works as a simple wget client.

That’s an important difference because in case of the proxy, you cannot dequeue 
the data from the fifo before you send it to the actual destination and it gets 
acknowledged. That means, you need to wait at least one rtt (to the final 
destination) before you can make space in the fifo. If the final destination 
consuming the data is slower than the sender, you have an even bigger problem.

Try doing a simple wget client, builtin or with vcl, and you’ll note that data 
should be dequeued much faster than in the proxy case. 

You could improve the 200ms by forcing an ack out of the proxy to the sender 
once you get an ack from the receiver (this is what empties up space in the rx 
fifo on the sender side). But for that you need to monitor acks and push window 
updates. This works only if data is freed faster than the 200ms linux uses for 
probing. If you need to avoid that, to support the maximum throughput in proxy 
scenarios, you need to increase fifo sizes. 

> 
> The problem is not that we are slowly sending data, but that we are slowly 
> receiving data from the Linux stack, causing it to pause for 0.2 seconds. At 
> the same time, vpp reports errors like “Segment not in the receive window”. 

Probably the not in the receive window is generated by the last segment that 
fills the window. I’ll look into it once I have a bit of time, but in your case 
it doesn’t make too much of a difference, unfortunately. 

Florin

> 
> 
> [1] https://drive.google.com/open?id=1pC8yeQyldyysuloSc8rulhVC9Y0xs-Qr
> 
> -- 
> Max A.

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

View/Reply Online (#13582): https://lists.fd.io/g/vpp-dev/message/13582
Mute This Topic: https://lists.fd.io/mt/32582078/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] echo server crash with my certs/self signed cert. (tls uri)

2019-07-24 Thread Florin Coras
Hi Praveen, 

Glad it helped! 

Actually the one complaining is openssl. We enforce strict certificate 
verification only if the server hostname was provided at connect time. 

Florin 

> On Jul 24, 2019, at 7:41 PM, Praveen Kariyanahalli  
> wrote:
> 
> Thanks a lot. That tip helped a lot. My app_index was not set properly while 
> adding my cert.
> 
> I see my client complains about the self signed certificate. Is this 
> expected? See logs below
> 
> Regards
> -Praveen
> 
> Jul 25 02:39:02 myvpp1 vnet[1468]: create_api_loopback:330: 
> ecm->my_client_index 256
> Jul 25 02:39:02 myvpp1 vnet[1468]: echo_clients_attach:644: Starting appns_id 
> (nil)
> Jul 25 02:39:02 myvpp1 vnet[1468]: echo_clients_attach:680: Attach successful 
> 
> Jul 25 02:39:02 myvpp1 vnet[1468]: vnet_app_add_tls_cert:1302: 
> vnet_app_add_tls_cert try ...
> Jul 25 02:39:02 myvpp1 vnet[1468]: vnet_app_add_tls_cert:1307: 
> vnet_app_add_tls_cert Done
> Jul 25 02:39:02 myvpp1 vnet[1468]: echo_clients_attach:703: Cert add 
> successful 
> Jul 25 02:39:02 myvpp1 vnet[1468]: vnet_app_add_tls_key:1316: 
> vnet_app_add_tls_key try ...
> Jul 25 02:39:02 myvpp1 vnet[1468]: vnet_app_add_tls_key:1321: 
> vnet_app_add_tls_key Done
> Jul 25 02:39:02 myvpp1 vnet[1468]: echo_clients_attach:727: Key add 
> successful 
> Jul 25 02:39:02 myvpp1 vnet[1468]: tls_connect:541: New connect request 0 
> engine 2
> Jul 25 02:39:02 myvpp1 vnet[1468]: tls_session_connected_callback:468: TCP 
> connect for 0 returned 0. New connection [0]4000
> Jul 25 02:39:02 myvpp1 vnet[1468]: openssl_ctx_init_client:532: Initiating 
> handshake for [0]0
> Jul 25 02:39:02 myvpp1 vnet[1468]: openssl_ctx_handshake_rx:277:  failed 
> verify: self signed certificate
> Jul 25 02:39:02 myvpp1 vnet[1468]: openssl_ctx_handshake_rx:296: Handshake 
> for 0 complete. TLS cipher is TLS_AES_256_GCM_SHA384
> Jul 25 02:39:02 myvpp1 vnet[1468]: send_data_chunk:60: send_data_chunk ... 
> test_buf_offset 0 s->bytes_sent 0 test_buf_len 4194304
> Jul 25 02:39:02 myvpp1 vnet[1468]: receive_data_chunk:146: receive_data_chunk 
> ecm->test_bytes 0
> Jul 25 02:39:02 myvpp1 vnet[1468]: receive_data_chunk:162: receive_data_chunk 
> ecm->test_bytes 0, n_read 8192
> Jul 25 02:39:02 myvpp1 vnet[1468]: tls_disconnect:550: Disconnecting 4000
> 
> ᐧ
> 
> On Tue, Jul 23, 2019 at 10:59 PM Praveen Kariyanahalli 
> mailto:praveen.ha...@gmail.com>> wrote:
> I havent changed anything in the listener handler (this is latest vpp code as 
> is). Just changed the certs thats all. I will sprinkle debugs and run it 
> under gdb and get back to u. Thanks!
> 
> 
> ᐧ
> 
> On Tue, Jul 23, 2019, 10:43 PM Florin Coras  <mailto:fcoras.li...@gmail.com>> wrote:
> Hi Praveen, 
> 
> It looks like the tls listener was not properly initialized. I’d recommend 
> running a debug image from gdb to get more info. 
> 
> Probably openssl complained about the parameters on listen but the error was 
> not handled. If I’m right, this [1] should better handle the failed listen. 
> 
> Florin
> 
> [1] https://gerrit.fd.io/r/c/20815/ <https://gerrit.fd.io/r/c/20815/>
> 
>> On Jul 23, 2019, at 10:05 PM, Praveen Kariyanahalli > <mailto:praveen.ha...@gmail.com>> wrote:
>> 
>> Hi All
>> 
>> I replaced the testca/certs with my CA chain (self signed) and my server 
>> client certs. When I run it I am seeing some weird assert on the server 
>> side. Can anyone please throw some light on this? 
>> 
>> Thanks in advance
>> Praveen
>> 
>> Jul 24 04:56:11 myvpp1 vnet[1299]: 
>> /home/pk/vpp/src/plugins/tlsopenssl/tls_openssl.c:105 (openssl_lctx_get) 
>> assertion `! pool_is_free (openssl_main.lctx_pool, _e)' fails
>> Jul 24 04:56:11 myvpp1 vnet[1299]: received signal SIGABRT, PC 0x7f994cd66e97
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #0  0x7f994d730c13 0x7f994d730c13
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #1  0x7f994d43e890 0x7f994d43e890
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #2  0x7f994cd66e97 gsignal + 0xc7
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #3  0x7f994cd68801 abort + 0x141
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #4  0x55a88d861c8d 0x55a88d861c8d
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #5  0x7f994d14c8b3 0x7f994d14c8b3
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #6  0x7f994d14cc82 _clib_error + 0x2c0
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #7  0x7f9903c80d89 openssl_lctx_get + 
>> 0xeb
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #8  0x7f9903c81fd2 0x7f9903c81fd2
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #9  0x7f994e7a2dbd 0x7f994e7a2dbd
>> Jul 24 04:56:11 myvpp1 vnet[1299]: #10 0x7f994e7a3

Re: [vpp-dev] TCP host stack & small size fifo

2019-07-24 Thread Florin Coras
Hi Max, 

Note how whenever acks go from 192.168.0.1 to 192.168.0.200, the window is 
constantly 8k, it never drops, i.e., that buffer never fills. If you pick a 
segment, say seq 18825 -> 20273, it’s sent at time 0.000545 and it’s acked at 
0.000570. So, the ack went out after 25us and by that time the data was already 
consumed (since the window didn’t change)? In other cases, you can see it ack 
bursts of 4 packets (so 5792B) in ~40us.

Therefore, is the data read by the application much faster or is the advertised 
rcv window unrelated to the amount of data buffered? Obviously, if the latter, 
the actual buffer is larger than what you’ve configured. Also, does mtcp act as 
proxy in this case as well?

Florin

> On Jul 24, 2019, at 11:38 AM, Max A. via Lists.Fd.Io 
>  wrote:
> 
> Hi Florin,
> 
> 
> 
> Well, the question there is how large are the rx buffers. If you never see a 
> zero rcv window advertised to the sender, I suspect the rx buffer is large 
> enough to sustain the throughput. 
> 
> Using the reference [1], you can view a dump of downloading the same file 
> from the same linux server using the mtcp host stack (buffer size has been 
> set to 8192 bytes). As you can see from the dump, there is no one buffer 
> overflow. And in this case, even using an 8k buffer, we get good bandwidth.
> 
> Thanks.
> 
> [1] https://drive.google.com/open?id=15-sEAQ5BVCVgi36pqXD3cRX_mUxRk9r1 
> 
> 
> -- 
> Max A.
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13573): https://lists.fd.io/g/vpp-dev/message/13573 
> 
> Mute This Topic: https://lists.fd.io/mt/32582078/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13575): https://lists.fd.io/g/vpp-dev/message/13575
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

2019-07-24 Thread Florin Coras
Hi Max, 

Inline.

> On Jul 24, 2019, at 10:09 AM, Max A.  wrote:
> 
> 
> Hi Florin,
> 
> I made a simple epoll tcp proxy (using vcl) and saw the same behavior.
> 
> I increased the fifo size to 16k, but I got exactly the same effect. A full 
> dump for a session with a buffer size of 16k can be obtained by reference [1] 
> (192.168.0.1 is the interface on vpp, 192.168.0.200 is the linux host with 
> nginx).

Since fifos are fixed, you’ll see the same effect as long as the sender is 
faster than the rate at which data is dequeued out of the rx fifo. 

> 
> Maybe we should not allow full buffer filling?

As explained above, as long as the sender is faster, this will happen. Still, 
out of curiosity, can you try this [1] to see if it changes linux’s behavior in 
any way? Although, I suspect the linux’s window probe timer, after a zero 
window, is not smaller than min rto (which is the 200 ms you’re seeing). 

[1] https://gerrit.fd.io/r/c/20830/ <https://gerrit.fd.io/r/c/20830/>

> 
> P.S. I tested several host stacks working with dpdk, but only in vpp this 
> behavior is observed.

Well, the question there is how large are the rx buffers. If you never see a 
zero rcv window advertised to the sender, I suspect the rx buffer is large 
enough to sustain the throughput. We will eventually support auto-tunning of 
the fifos (i.e., dynamically grow/shrink them based on observed throughput) but 
until then, you either request large enough fifos or write a builtin proxy that 
does the auto-tunning of the fifos via the shrink/grow fifo apis (e.g., 
segment_manager_grow_fifo)

Florin

> 
> Thanks.
> 
> [1]  https://drive.google.com/open?id=1JV1zSpggwEoWdeddDR8lcY3yeQRY6-B3 
> <https://drive.google.com/open?id=1JV1zSpggwEoWdeddDR8lcY3yeQRY6-B3> 
> 
> Среда, 24 июля 2019, 17:45 +03:00 от Florin Coras :
> 
> Hi, 
> 
> It seems that linux is reluctant to send a segment smaller than the mss, so 
> it probably delays sending it. Since there’s little fifo space, that’s pretty 
> much unavoidable. 
> 
> Still, note that as you increase the number of sessions, if all send traffic 
> at the same rate, then their fair share will be considerably lower than the 
> maximum you can achieve on your interfaces. If you expect some sessions to be 
> “elephant flows”, you could solve the issue by growing their fifos (see 
> segment_manager_grow_fifo) from the app. The builtin tcp proxy does not 
> support this at this time, so you’ll have to do it yourself.  
> 
> Florin
> 
> > On Jul 24, 2019, at 1:34 AM, max1976 via Lists.Fd.Io 
> > mailto:max1976=mail...@lists.fd.io>> wrote:
> > 
> > Hello,
> > 
> > Experimenting with the size of fifo, I saw a problem. The smaller the size 
> > of the fifo, the more often tcp window overflow errors occur (Segment not 
> > in receive window in vpp terminology). In the dump [1], is shown the data 
> > exchange between the vpp tcp proxy (192.168.0.1) and the nginx server under 
> > Linux (192.168.0.200), the size of the rx fifo in the vpp is set to 8192 
> > bytes. The red arrow indicates that the vpp is waiting for the latest data 
> > to fill the buffer. The green arrow indicates that the Linux host stack is 
> > sending data with a significant delay.
> > This behavior significantly reduces throughput. I plan to use a large 
> > number of simultaneous sessions, so I can not set the size of the fifo too 
> > large. How can I solve this problem?
> > 
> > Thanks.
> > [1] https://monosnap.com/file/XfDjcqvpofIR7fJ6lEXgoyCB17LdfY 
> > <https://monosnap.com/file/XfDjcqvpofIR7fJ6lEXgoyCB17LdfY> 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#13555): https://lists.fd.io/g/vpp-dev/message/13555 
> > <https://lists.fd.io/g/vpp-dev/message/13555>
> > Mute This Topic: https://lists.fd.io/mt/32582078/675152 
> > <https://lists.fd.io/mt/32582078/675152>
> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> > <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13567): https://lists.fd.io/g/vpp-dev/message/13567 
> <https://lists.fd.io/g/vpp-dev/message/13567>
> Mute This Topic: https://lists.fd.io/mt/32582078/1863201 
> <https://lists.fd.io/mt/32582078/1863201>
> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://lists.fd.io/g/vpp-dev/un

Re: [vpp-dev] TCP host stack & small size fifo

2019-07-24 Thread Florin Coras
Pretty much. We advertise whatever space we have left in the fifo as opposed to 
0 and as result linux backs off.

TCP_NODELAY can force what looks like the problematic packet out sooner. 
However, because of the small rx fifo, next rcv window will zero and the whole 
transfer will stall there until the other side of the proxy consumes the data. 

Florin

> On Jul 24, 2019, at 9:12 AM, Andrew  Yourtchenko  wrote:
> 
> Just reading the description and not having peeked into the sniffer
> trace, I wondered if is it this behavior a side effect of mitigation
> of [1], consequently, are the linux side sockets marked as no_delay ?
> [2]
> 
> [1]: https://en.wikipedia.org/wiki/Silly_window_syndrome
> 
> [2]: 
> https://stackoverflow.com/questions/17842406/how-would-one-disable-nagles-algorithm-in-linux
> 
> --a
> 
> On 7/24/19, Florin Coras  wrote:
>> Hi,
>> 
>> It seems that linux is reluctant to send a segment smaller than the mss, so
>> it probably delays sending it. Since there’s little fifo space, that’s
>> pretty much unavoidable.
>> 
>> Still, note that as you increase the number of sessions, if all send traffic
>> at the same rate, then their fair share will be considerably lower than the
>> maximum you can achieve on your interfaces. If you expect some sessions to
>> be “elephant flows”, you could solve the issue by growing their fifos (see
>> segment_manager_grow_fifo) from the app. The builtin tcp proxy does not
>> support this at this time, so you’ll have to do it yourself.
>> 
>> Florin
>> 
>>> On Jul 24, 2019, at 1:34 AM, max1976 via Lists.Fd.Io
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Experimenting with the size of fifo, I saw a problem. The smaller the size
>>> of the fifo, the more often tcp window overflow errors occur (Segment not
>>> in receive window in vpp terminology). In the dump [1], is shown the data
>>> exchange between the vpp tcp proxy (192.168.0.1) and the nginx server
>>> under Linux (192.168.0.200), the size of the rx fifo in the vpp is set to
>>> 8192 bytes. The red arrow indicates that the vpp is waiting for the latest
>>> data to fill the buffer. The green arrow indicates that the Linux host
>>> stack is sending data with a significant delay.
>>> This behavior significantly reduces throughput. I plan to use a large
>>> number of simultaneous sessions, so I can not set the size of the fifo too
>>> large. How can I solve this problem?
>>> 
>>> Thanks.
>>> [1] https://monosnap.com/file/XfDjcqvpofIR7fJ6lEXgoyCB17LdfY
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#13555): https://lists.fd.io/g/vpp-dev/message/13555
>>> Mute This Topic: https://lists.fd.io/mt/32582078/675152
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
>>> [fcoras.li...@gmail.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> 

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

View/Reply Online (#13569): https://lists.fd.io/g/vpp-dev/message/13569
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

2019-07-24 Thread Florin Coras
Hi, 

It seems that linux is reluctant to send a segment smaller than the mss, so it 
probably delays sending it. Since there’s little fifo space, that’s pretty much 
unavoidable. 

Still, note that as you increase the number of sessions, if all send traffic at 
the same rate, then their fair share will be considerably lower than the 
maximum you can achieve on your interfaces. If you expect some sessions to be 
“elephant flows”, you could solve the issue by growing their fifos (see 
segment_manager_grow_fifo) from the app. The builtin tcp proxy does not support 
this at this time, so you’ll have to do it yourself.  

Florin

> On Jul 24, 2019, at 1:34 AM, max1976 via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Experimenting with the size of fifo, I saw a problem. The smaller the size of 
> the fifo, the more often tcp window overflow errors occur (Segment not in 
> receive window in vpp terminology). In the dump [1], is shown the data 
> exchange between the vpp tcp proxy (192.168.0.1) and the nginx server under 
> Linux (192.168.0.200), the size of the rx fifo in the vpp is set to 8192 
> bytes. The red arrow indicates that the vpp is waiting for the latest data to 
> fill the buffer. The green arrow indicates that the Linux host stack is 
> sending data with a significant delay.
> This behavior significantly reduces throughput. I plan to use a large number 
> of simultaneous sessions, so I can not set the size of the fifo too large. 
> How can I solve this problem?
> 
> Thanks.
> [1] https://monosnap.com/file/XfDjcqvpofIR7fJ6lEXgoyCB17LdfY 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13555): https://lists.fd.io/g/vpp-dev/message/13555
> Mute This Topic: https://lists.fd.io/mt/32582078/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13567): https://lists.fd.io/g/vpp-dev/message/13567
Mute This Topic: https://lists.fd.io/mt/32582078/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] echo server crash with my certs/self signed cert. (tls uri)

2019-07-23 Thread Florin Coras
Hi Praveen, 

It looks like the tls listener was not properly initialized. I’d recommend 
running a debug image from gdb to get more info. 

Probably openssl complained about the parameters on listen but the error was 
not handled. If I’m right, this [1] should better handle the failed listen. 

Florin

[1] https://gerrit.fd.io/r/c/20815/

> On Jul 23, 2019, at 10:05 PM, Praveen Kariyanahalli  
> wrote:
> 
> Hi All
> 
> I replaced the testca/certs with my CA chain (self signed) and my server 
> client certs. When I run it I am seeing some weird assert on the server side. 
> Can anyone please throw some light on this? 
> 
> Thanks in advance
> Praveen
> 
> Jul 24 04:56:11 myvpp1 vnet[1299]: 
> /home/pk/vpp/src/plugins/tlsopenssl/tls_openssl.c:105 (openssl_lctx_get) 
> assertion `! pool_is_free (openssl_main.lctx_pool, _e)' fails
> Jul 24 04:56:11 myvpp1 vnet[1299]: received signal SIGABRT, PC 0x7f994cd66e97
> Jul 24 04:56:11 myvpp1 vnet[1299]: #0  0x7f994d730c13 0x7f994d730c13
> Jul 24 04:56:11 myvpp1 vnet[1299]: #1  0x7f994d43e890 0x7f994d43e890
> Jul 24 04:56:11 myvpp1 vnet[1299]: #2  0x7f994cd66e97 gsignal + 0xc7
> Jul 24 04:56:11 myvpp1 vnet[1299]: #3  0x7f994cd68801 abort + 0x141
> Jul 24 04:56:11 myvpp1 vnet[1299]: #4  0x55a88d861c8d 0x55a88d861c8d
> Jul 24 04:56:11 myvpp1 vnet[1299]: #5  0x7f994d14c8b3 0x7f994d14c8b3
> Jul 24 04:56:11 myvpp1 vnet[1299]: #6  0x7f994d14cc82 _clib_error + 0x2c0
> Jul 24 04:56:11 myvpp1 vnet[1299]: #7  0x7f9903c80d89 openssl_lctx_get + 
> 0xeb
> Jul 24 04:56:11 myvpp1 vnet[1299]: #8  0x7f9903c81fd2 0x7f9903c81fd2
> Jul 24 04:56:11 myvpp1 vnet[1299]: #9  0x7f994e7a2dbd 0x7f994e7a2dbd
> Jul 24 04:56:11 myvpp1 vnet[1299]: #10 0x7f994e7a316b 
> tls_session_accept_callback + 0xf0
> Jul 24 04:56:11 myvpp1 vnet[1299]: #11 0x7f994e76c90e 
> app_worker_accept_notify + 0x33
> Jul 24 04:56:11 myvpp1 vnet[1299]: #12 0x7f994e727cff 
> session_stream_accept_notify + 0x62
> Jul 24 04:56:11 myvpp1 vnet[1299]: #13 0x7f994dd08768 0x7f994dd08768
> Jul 24 04:56:11 myvpp1 vnet[1299]: #14 0x7f994dd08fd6 
> tcp4_rcv_process_node_fn_avx2 + 0x2d
> ᐧ
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13552): https://lists.fd.io/g/vpp-dev/message/13552
> Mute This Topic: https://lists.fd.io/mt/32581195/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13553): https://lists.fd.io/g/vpp-dev/message/13553
Mute This Topic: https://lists.fd.io/mt/32581195/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] nginx+vpp with epoll pattern failed #vpp #ngnix #epoll

2019-07-22 Thread Florin Coras
Hi, 

It’s not clear from your email if you’re trying it out with ldp or directly 
with vcl. 

If you’re trying a direct integration with vcl, note that vcl epoll is edge 
triggered, so you must read all data before waiting for another rx event. 

Florin

> On Jul 22, 2019, at 7:32 PM, fjc...@hotmail.com wrote:
> 
> We use vpp as tcp protocol stack to work with nginx in epoll pattern, but 
> nginx cannot get epollout event. 
> When we use sendfile pattern, it can transfer file completely. However, if we 
> use aio pattern, nginx cannot get epollout event, and the file cannot be 
> transferred completely. 
> Meanwhile, the process hangs. 
> 
> When we use nginx with kernel tcp protocol stack, it can work normally. 
> Now, we want to know if vpp can work with nginx.
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13542): https://lists.fd.io/g/vpp-dev/message/13542
> Mute This Topic: https://lists.fd.io/mt/32566351/675152
> Mute #epoll: https://lists.fd.io/mk?hashtag=epoll=1480544
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480544
> Mute #ngnix: https://lists.fd.io/mk?hashtag=ngnix=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13543): https://lists.fd.io/g/vpp-dev/message/13543
Mute This Topic: https://lists.fd.io/mt/32566351/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #epoll: https://lists.fd.io/mk?hashtag=epoll=1480452
Mute #ngnix: https://lists.fd.io/mk?hashtag=ngnix=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] VCL defaults to app-local-scope

2019-07-11 Thread Florin Coras
Hi Alok, 

Inline.

> On Jul 11, 2019, at 5:19 PM, Alok Nikhil (anikhil) via Lists.Fd.Io 
>  wrote:
> 
> Thanks Florin! That works. 
> 
> Just a couple of more questions -
> 1) You mentioned the VCL library was undergoing a refactor. Is it now stable 
> enough for production use?

Yes, VCL refactoring was completed several releases ago. It should be in good 
shape now. 

> 2) VCL doesn't clean up any sessions, if the app crashes and doesn't do close 
> the session before doing so. Is this expected? Would the work-around be to 
> have an external agent clean the session up through vppctl?

You’ll have to wait until the binary api reaper figures out that vcl’s binary 
api client has died. At that point, all sessions should be forcefully cleaned 
up. 

Florin

> 
> --Alok -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13495): https://lists.fd.io/g/vpp-dev/message/13495
> Mute This Topic: https://lists.fd.io/mt/32435763/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13496): https://lists.fd.io/g/vpp-dev/message/13496
Mute This Topic: https://lists.fd.io/mt/32435763/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] VCL defaults to app-local-scope

2019-07-11 Thread Florin Coras
Hi Alok, 

VCL, on master, defaults to no scope set. Local and global scope are set only 
if requested in vcl.config as “app-local-scope” or “app-global-scope” or if set 
via environment variables, like in your example lower. For more details check 
vcl_cfg.c. Session layer interprets no scope set as global scope only, so as 
long as no env variables are set and vcl.conf is like the one you have lower, 
global scope should be the one the app gets. 

Now, regarding the sock test server and client, are you testing through the 
stack or cut-through connectivity? If the latter, then you need the local scope 
to be configured, otherwise cut-through connections don’t work. 

Also, take a look at [1] instead of sock_test_client/server apps if you’re 
interested in through the stack throughput testing. Iperf can also be used for 
cut-through connections but the only example you can find is here [2], so 
you’ll have to parse a bit of python to understand it. 

Hope this helps, 
Florin

[1] https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 

[2] https://git.fd.io/vpp/tree/test/test_vcl.py#n287 



> On Jul 11, 2019, at 3:16 PM, Alok Nikhil (anikhil) via Lists.Fd.Io 
>  wrote:
> 
> I was following the discussion on this thread - VCL-Error 
> 
> That led me to believe VCL starts with a global-scope as the default. 
> However, I tried a hosting the sock_test_server and the client cannot connect 
> unless I export VCL_APP_SCOPE_LOCAL=true
> 
> This is what my /etc/vpp/vcl.conf looks like
> vcl {
>   heapsize 1024M
>   rx-fifo-size 400
>   tx-fifo-size 400
>   api-socket-name /var/run/vpp/vpp-api.sock
> }
> 
> Is the default behaviour now changed? -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13493): https://lists.fd.io/g/vpp-dev/message/13493
> Mute This Topic: https://lists.fd.io/mt/32435763/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [EXTERNAL] [vpp-dev] VPP Router Plugin or alternatives

2019-07-05 Thread Florin Coras
Just a quick note on punting tcp: we can punt TCP flows that do not match a 
configured session but at this time, we can’t punt to a specific node, instead 
they are punted to ip4/6-punt. 

As for TCP-MD5, it could be implemented, but I have my hands full these days. 
And, to rant for a second, why won’t BGP do something decent like TLS? 

Florin

> On Jul 5, 2019, at 6:37 AM, Chris Luke  wrote:
> 
> TCP-MD5 may technically be obsolete, but it’s used widely for protecting BGP 
> sessions in the real world. Noting the comments in 
> https://tools.ietf.org/html/rfc5925#page-35 
>  that any AO implementation 
> SHOULD support MD5, I would suggest starting with an RFC 2385 TCP-MD5 
> implementation. It may be legacy, but you need it anyway and it gets you 
> significant real world coverage immediately.
>  
> Chris.
>  
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Burt Silverman
> Sent: Friday, July 5, 2019 09:09
> To: Jim Thompson mailto:j...@netgate.com>>
> Cc: Steuer Heribert mailto:ste...@patronas.com>>; 
> vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [EXTERNAL] Re: [vpp-dev] VPP Router Plugin or alternatives
>  
> >TCP-MD5 needs to be implemented in the host stack before a 
> >standards-compliant BGP could be accomplished.
>  
> Or TCP-AO, RFC 5925, instead, as it has obsoleted RFC 2385?
>  
> Burt
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13453): https://lists.fd.io/g/vpp-dev/message/13453 
> 
> Mute This Topic: https://lists.fd.io/mt/32317374/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13455): https://lists.fd.io/g/vpp-dev/message/13455
Mute This Topic: https://lists.fd.io/mt/32318664/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] TCP host stack

2019-07-02 Thread Florin Coras
Hi, 

Yes, it should. But there are several things that must be considered:
- the proxy code is not optimized at all. It’s just a toy
- fifos (buffers for connections) are not auto-tunnable at this point. To 
achieve a high throughput you need to manually configure large fifos. Here’s[1] 
how we do throughput testing with 1 connection. The fifos can be grown/shrunk 
but the proxy does not make use of that. 
- whenever large number of connection is needed, the fifo segments (place where 
the fifos are allocated) should be configured to be pretty large. Note however 
that configuring large fifos (due to the requirement above) will still quickly 
eat up fifo-segment memory. 

Florin

[1] https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 


> On Jul 2, 2019, at 5:52 AM, max1976 via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Can a host stack handle a large number of connections? I tried to test the 
> tcp proxy from the vpp (tested with wrk) and I see that this proxy shows a 
> very low bandwidth even compared to the TCP proxy under Linux.
> 
> Thanks. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13427): https://lists.fd.io/g/vpp-dev/message/13427
> Mute This Topic: https://lists.fd.io/mt/32285647/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


[vpp-dev] centos jobs failing

2019-07-01 Thread Florin Coras
It seems the centos package expired in packagecloud. Ed is working on the 
problem. 

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

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


Re: [vpp-dev] VPP 19.04 TCP stack issue: I think TCP stack notify the FIN reception immaturely #vnet

2019-06-28 Thread Florin Coras
Hi, 

Well, yes. VPP tcp won’t send out of order fins because it waits for all the 
data to be acked before sending the fin. Still, others may do it, so here’s a 
quick fix for that [1]. 

Thanks,
Florin 

[1] https://gerrit.fd.io/r/c/20403/ 

> On Jun 28, 2019, at 7:25 AM, guangwei  wrote:
> 
> I think the FIN is reported to session layer only when it's indeed all the 
> data which allowed in SEQ window has received, but from code, when the packet 
> flaged with FIN
> no matter whether it's a Out-Of-Order segment or not , no matter whether it's 
> data all in the allowed window or not, the stack will treat this FIN as 
> normal case and notify the session layer. Something I missed in code ? 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13396): https://lists.fd.io/g/vpp-dev/message/13396
> Mute This Topic: https://lists.fd.io/mt/32242280/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread Florin Coras
Here’s the patch [1]. 

Thanks, 
Florin

[1] https://gerrit.fd.io/r/c/20404/ <https://gerrit.fd.io/r/c/20404/>

> On Jun 28, 2019, at 7:54 AM, guangwei  wrote:
> 
> Yes, please fixed it, I'am just searching the code, no environment to verify 
> it.
> 
> 
> 
> At 2019-06-28 22:45:23, "Florin Coras"  wrote:
> >Hi, 
> >
> >That is correct. You want to provide the patch or should I do it?
> >
> >Thanks,
> >Florin
> >
> >> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
> >> 
> >> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please 
> >> look following comment in line.
> >> 
> >> tcp46_rcv_process_inline
> >> {
> >> ...
> >>  /* 5: check the ACK field  */
> >> ...
> >>  case TCP_STATE_CLOSE_WAIT:
> >>/* Do the same processing as for the ESTABLISHED state. */
> >>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
> >>  goto drop;
> >>  
> >>if (!(tc0->flags & TCP_CONN_FINPNDG))
> >>  break;
> >>  
> >>/* Still have outstanding tx data */
> >>if (transport_max_tx_dequeue (>connection))<Here, I 
> >> think should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
> >>  break;
> >>  
> >>tcp_send_fin (tc0);
> >>tcp_connection_timers_reset (tc0);
> >>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
> >>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
> >>break;
> >> 
> >> ...
> >> 
> >> }
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >> Links: You receive all messages sent to this group.
> >> 
> >> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
> >> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> >> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> >> Group Owner: vpp-dev+ow...@lists.fd.io
> >> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> >> -=-=-=-=-=-=-=-=-=-=-=-
> 
> 
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13398): https://lists.fd.io/g/vpp-dev/message/13398
> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] A question about TCP statck in version 19.04, when passive FIN coming in first, then APP close with TX fifo not empty, it seem can't have chance to send FIN out. #vnet

2019-06-28 Thread Florin Coras
Hi, 

That is correct. You want to provide the patch or should I do it?

Thanks,
Florin

> On Jun 28, 2019, at 6:10 AM, guangwei  wrote:
> 
> Now, I'am searching the TCP stack of VPP 19.04, and have a doubt, please look 
> following comment in line.
> 
> tcp46_rcv_process_inline
> {
> ...
>  /* 5: check the ACK field  */
> ...
>  case TCP_STATE_CLOSE_WAIT:
>/* Do the same processing as for the ESTABLISHED state. */
>if (tcp_rcv_ack (wrk, tc0, b0, tcp0, ))
>  goto drop;
>  
>if (!(tc0->flags & TCP_CONN_FINPNDG))
>  break;
>  
>/* Still have outstanding tx data */
>if (transport_max_tx_dequeue (>connection)) should check burst_acked  as TCP_STATE_FIN_WAIT_1 do. 
>  break;
>  
>tcp_send_fin (tc0);
>tcp_connection_timers_reset (tc0);
>tcp_connection_set_state (tc0, TCP_STATE_LAST_ACK);
>tcp_timer_set (tc0, TCP_TIMER_WAITCLOSE, TCP_2MSL_TIME);
>break;
> 
> ...
> 
> }
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13393): https://lists.fd.io/g/vpp-dev/message/13393
> Mute This Topic: https://lists.fd.io/mt/32241597/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] test-debug in the CI

2019-06-25 Thread Florin Coras
This [1] seems to solve sctp issues with debug images locally. 

Florin

[1] https://gerrit.fd.io/r/c/20337/ 

> On Jun 25, 2019, at 12:10 PM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> The BIER tests cause ASSERT failures. I’ll have a quick look, then turn the 
> problem over to Neale if I can’t solve it.
>  
> D.
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Paul Vinciguerra
> Sent: Tuesday, June 25, 2019 2:55 PM
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] test-debug in the CI
>  
> I set up a job to view the results of debug images.
> 
> For anyone who might be interested.
> https://gerrit.fd.io/r/#/c/20228/ 
> 
> logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-beta-verify-master-ubuntu1804/7991
>  
> 
> 
> non-debug image EXTENDED_TESTS=1 can be seen here.
> https://gerrit.fd.io/r/#/c/20229/ 
> 
> 
> Paul 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13371): https://lists.fd.io/g/vpp-dev/message/13371 
> 
> Mute This Topic: https://lists.fd.io/mt/32206961/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13374): https://lists.fd.io/g/vpp-dev/message/13374
Mute This Topic: https://lists.fd.io/mt/32206961/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] TLS client app

2019-06-23 Thread Florin Coras
Hi, 

No, we’re not exposing the server certificate in the session connected 
notification because that api is generic, i.e., used for all transports. If you 
need to grab the server certificate out of a tls connection, you’ll need to add 
a separate api that for a given session handles returns the certificate. 

Florin

> On Jun 23, 2019, at 12:35 AM, max1976 via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Can I get a server certificate (by calling SSL_get_peer_certificate) when the 
> client connected to the server (in the event session_connected_callback) in 
> the client tls app by usign openssl plugin?
> 
> Thanks. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13350): https://lists.fd.io/g/vpp-dev/message/13350
> Mute This Topic: https://lists.fd.io/mt/32175198/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13351): https://lists.fd.io/g/vpp-dev/message/13351
Mute This Topic: https://lists.fd.io/mt/32175198/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] Commit Subjects

2019-06-17 Thread Florin Coras
Hi Jon, 

Yup, it has to match a maintainer “I” entry and yes, that’s where the script 
is. :-)

Florin

> On Jun 17, 2019, at 1:16 PM, Jon Loeliger via Lists.Fd.Io 
>  wrote:
> 
> And now this: 
> 
> === ERROR ===
> Unknown feature 'Consolidate' in commit 'Subject:' line.
> Feature must exist in MAINTAINERS file. If this commit intruduces 
> new feature, then this commit must add new entry into the 
> MAINTAINERS file.
> === ERROR ===
> Does it just check the first word on the subject line regardless?
> What else is being checked?  Poorly?
> Does it _have_ to match a MAINTAINER I: word?
> 
> Where is this script?  Rhetorical.  It is here:
> extras/scripts/check_commit_msg.sh
> 
> Now I at least know what I am up against.
> 
> jdl
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13306): https://lists.fd.io/g/vpp-dev/message/13306
> Mute This Topic: https://lists.fd.io/mt/32096793/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13307): https://lists.fd.io/g/vpp-dev/message/13307
Mute This Topic: https://lists.fd.io/mt/32096793/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] Transparent proxy app

2019-06-14 Thread Florin Coras
Hi, 

By default the stack only accepts “for-us” packets, i.e., packets that have as 
destination ip one vpp’s interface ips. To support transparent proxying you’d 
have to 1) write your own feature that intercepts traffic and delivers it to 
the stack and 2) your own transparent proxy app. 

Florin

> On Jun 14, 2019, at 9:32 AM, max1976 via Lists.Fd.Io 
>  wrote:
> 
> Hello,
> 
> Does vpp support transparent proxy mode for applications like tproxy in Linux?
> 
> Thanks. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13287): https://lists.fd.io/g/vpp-dev/message/13287
> Mute This Topic: https://lists.fd.io/mt/32065725/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13289): https://lists.fd.io/g/vpp-dev/message/13289
Mute This Topic: https://lists.fd.io/mt/32065725/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] setsockopt with TCP_NODELAY

2019-06-12 Thread Florin Coras
Unfortunately, we don’t support any of those options at this time. In 
particular, the stack won’t delay segments and tcp doesn’t do keepalives. Do 
you really need those?

If you need to constrain tcp mss, you can indirectly do it by configuring the 
tcp mtu as a vpp startup parameter. You can’t do it per connection at this 
time.  

Florin

> On Jun 12, 2019, at 12:01 PM, Nataraj Batchu  wrote:
> 
> Hi Florin,
> 
> Thanks for reply. My question is setsockopt() for not yet established 
> sessions i.e before connect(). I was trying to clearing TCP_NODELAY, setting 
> TCP_MAXSEG(to much lower than interface MTU) and TCP_KEEPINTVL. These options 
> need to be communicating to the vnet right?  I was looking for that.
> 
> Thanks,
> -Nataraj
> 
> On Wed, Jun 12, 2019 at 11:14 AM Florin Coras  <mailto:fcoras.li...@gmail.com>> wrote:
> Hi Nataraj, 
> 
> TCP defaults to TCP_NODELAY behavior, unless you need Nagle’s algorithm on, 
> you should be fine. 
> 
> As for the socket options, no. At this time, ldp cannot change properties for 
> established tcp connections. What sort of things are you missing?
> 
> Thanks,
> Florin 
> 
> > On Jun 12, 2019, at 11:04 AM, Nataraj Batchu  > <mailto:nataraj.bat...@gmail.com>> wrote:
> > 
> > Hi,
> > 
> > I was trying to use TCP_NODELAY socket option in my application. But I see 
> > that relevant code is "VPP-TBD" in vppcom.c. I see same comment for most of 
> > socket options.  Is there any other branch where code is available? If not, 
> > are there any plans to support setsockopt that involve communicating VPP 
> > TCP core.  
> > 
> > case VPPCOM_ATTR_SET_TCP_NODELAY:
> >   if (buffer && buflen && (*buflen == sizeof (int)))
> >  {
> >/* VPP-TBD */
> >if (*(int *) buffer)
> >  VCL_SESS_ATTR_SET (session->attr, VCL_SESS_ATTR_TCP_NODELAY);
> >else
> >  VCL_SESS_ATTR_CLR (session->attr, VCL_SESS_ATTR_TCP_NODELAY);
> >  
> >VDBG (2, "VPPCOM_ATTR_SET_TCP_NODELAY: %d, buflen %d, #VPP-TBD#",
> >  VCL_SESS_ATTR_TEST (session->attr, VCL_SESS_ATTR_TCP_NODELAY),
> >  *buflen);
> >  }
> >  
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#13268): https://lists.fd.io/g/vpp-dev/message/13268 
> > <https://lists.fd.io/g/vpp-dev/message/13268>
> > Mute This Topic: https://lists.fd.io/mt/32043473/675152 
> > <https://lists.fd.io/mt/32043473/675152>
> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev%2bow...@lists.fd.io>
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> > <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
> > <mailto:fcoras.li...@gmail.com>]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> 
> 
> -- 
> Thanks,
> -Nataraj

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

View/Reply Online (#13271): https://lists.fd.io/g/vpp-dev/message/13271
Mute This Topic: https://lists.fd.io/mt/32043473/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] setsockopt with TCP_NODELAY

2019-06-12 Thread Florin Coras
Hi Nataraj, 

TCP defaults to TCP_NODELAY behavior, unless you need Nagle’s algorithm on, you 
should be fine. 

As for the socket options, no. At this time, ldp cannot change properties for 
established tcp connections. What sort of things are you missing?

Thanks,
Florin 

> On Jun 12, 2019, at 11:04 AM, Nataraj Batchu  wrote:
> 
> Hi,
> 
> I was trying to use TCP_NODELAY socket option in my application. But I see 
> that relevant code is "VPP-TBD" in vppcom.c. I see same comment for most of 
> socket options.  Is there any other branch where code is available? If not, 
> are there any plans to support setsockopt that involve communicating VPP TCP 
> core.  
> 
> case VPPCOM_ATTR_SET_TCP_NODELAY:
>   if (buffer && buflen && (*buflen == sizeof (int)))
>  {
>/* VPP-TBD */
>if (*(int *) buffer)
>  VCL_SESS_ATTR_SET (session->attr, VCL_SESS_ATTR_TCP_NODELAY);
>else
>  VCL_SESS_ATTR_CLR (session->attr, VCL_SESS_ATTR_TCP_NODELAY);
>  
>VDBG (2, "VPPCOM_ATTR_SET_TCP_NODELAY: %d, buflen %d, #VPP-TBD#",
>  VCL_SESS_ATTR_TEST (session->attr, VCL_SESS_ATTR_TCP_NODELAY),
>  *buflen);
>  }
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13268): https://lists.fd.io/g/vpp-dev/message/13268
> Mute This Topic: https://lists.fd.io/mt/32043473/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13269): https://lists.fd.io/g/vpp-dev/message/13269
Mute This Topic: https://lists.fd.io/mt/32043473/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] sock_test_client/sock_test_server #vnet

2019-05-31 Thread Florin Coras
Hi, 

That script has not been recently maintained. Can’t you use instead vcl/ldp? 

From the logs, probably the server is not binding correctly. 

Florin

> On May 31, 2019, at 6:28 PM, nataraj.bat...@gmail.com wrote:
> 
> Update on sock_test_client/sock_test_server:
> 
> After running with LD_PRELOAD variable set, still see same issue. But the 
> problem is on server side. Its getting SYN packet sent by client but is 
> sending RST. Am I missing any config?
> 
> root@host2:~/vpp/build-root/build-vpp-native/vpp/bin# 
> LD_PRELOAD=/root/vpp/build-root/build-vpp-native/vpp/lib/libvcl_ldpreload.so 
> ./sock_test_server 1.1.0.2 10011
>  
> SERVER: Waiting for a client to connect on port 1...
>  
> SERVER: epoll_wait() timeout!
>  
> SERVER: epoll_wait() timeout!
>  
> SERVER: epoll_wait() timeout!
>  
> SERVER: epoll_wait() timeout!
> 
> 
> root@host1:~/vpp/build-root/build-vpp-native/vpp/bin# 
> LD_PRELOAD=/root/vpp/build-root/build-vpp-native/vpp/lib/libvcl_ldpreload.so 
> ./sock_test_client 1.1.0.2 10011
>  
> CLIENT: Connecting to server...
> ERROR in main(): Connection refused
> CLIENT: ERROR: connect failed (errno = 111)!
> vl_client_disconnect:331: queue drain: 585
> 
> show trace o/p on server:
> ===
> Packet 1
>  
> 03:52:39:089787: dpdk-input
>   TenGigabitEthernet3b/0/1 rx queue 0
>   buffer 0x9b381: current data 0, length 74, buffer-pool 0, ref-count 1, 
> totlen-nifb 0, trace 0x0
>   ext-hdr-valid 
>   l4-cksum-computed l4-cksum-correct 
>   PKT MBUF: port 0, nb_segs 1, pkt_len 74
> buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr 
> 0xab2ce0c0
> packet_type 0x111 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 (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>   RTE_PTYPE_L4_TCP (0x0100) TCP packet
>   IP4: 70:69:5a:48:08:b3 -> 00:be:75:72:3d:5f
>   TCP: 1.1.0.1 -> 1.1.0.2
> tos 0x00, ttl 255, length 60, checksum 0xfdca
> fragment id 0x7bec, flags DONT_FRAGMENT
>   TCP: 44839 -> 10011
> seq. 0xf06c93e7 ack 0x
> flags 0x02 SYN, tcp header: 40 bytes
> window 4096, checksum 0xa241
> 03:52:39:089798: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   IP4: 70:69:5a:48:08:b3 -> 00:be:75:72:3d:5f
> 03:52:39:089805: ip4-input-no-checksum
>   TCP: 1.1.0.1 -> 1.1.0.2
> tos 0x00, ttl 255, length 60, checksum 0xfdca
> fragment id 0x7bec, flags DONT_FRAGMENT
>   TCP: 44839 -> 10011
> seq. 0xf06c93e7 ack 0x
> flags 0x02 SYN, tcp header: 40 bytes
> window 4096, checksum 0xa241
> 03:52:39:089811: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   TCP: 1.1.0.1 -> 1.1.0.2
> tos 0x00, ttl 255, length 60, checksum 0xfdca
> fragment id 0x7bec, flags DONT_FRAGMENT
>   TCP: 44839 -> 10011
> seq. 0xf06c93e7 ack 0x
> flags 0x02 SYN, tcp header: 40 bytes
> window 4096, checksum 0xa241
> 03:52:39:089819: ip4-local
> TCP: 1.1.0.1 -> 1.1.0.2
>   tos 0x00, ttl 255, length 60, checksum 0xfdca
>   fragment id 0x7bec, flags DONT_FRAGMENT
> TCP: 44839 -> 10011
>   seq. 0xf06c93e7 ack 0x
>   flags 0x02 SYN, tcp header: 40 bytes
>   window 4096, checksum 0xa241
> 03:52:39:089821: tcp4-input
>   TCP: 44839 -> 10011
> seq. 0xf06c93e7 ack 0x
> flags 0x02 SYN, tcp header: 40 bytes
> window 4096, checksum 0xa241
>   [0:0][T] :::0->:::0   CLOSED 
> 03:52:39:089828: tcp4-reset
>   TCP: 10011 -> 44839
> seq. 0x ack 0xf06c93e8
> flags 0x14 RST ACK, tcp header: 20 bytes
> window 0, checksum 0x5334
>   [0:0][T] :::0->:::0   CLOSED  
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13192): https://lists.fd.io/g/vpp-dev/message/13192
> Mute This Topic: https://lists.fd.io/mt/31874159/675152
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VCL hoststack test & asserts

2019-05-24 Thread Florin Coras
After a closer look at this, it turns out udp-ping-local registers itself as a 
handler for hop-by-hop options and in doing so it “steals” MLDv2 listener 
reports. I suspect the latter should be handled by icmpv6 but, because the 
reports are generated with ip proto IP_PROTOCOL_IP6_HOP_BY_HOP_OPTIONS instead 
of IP_PROTOCOL_ICMP6, they end up in udp-ping-local. 

So, since I expect more people to depend on MLDv2, I guess that the short term 
solution is this [1], i.e., disable udp-ping. Long term, I guess we want to add 
a demux node for hop-by-hop options. 

Opinions?

Florin

[1] https://gerrit.fd.io/r/#/c/19816/ <https://gerrit.fd.io/r/#/c/19816/>

> On May 22, 2019, at 9:35 AM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> Hi Nathan, 
> 
> Just a quick reply. I regularly run make test-debug TEST=vcl so please 
> continue to do that and please report any issues you may encounter. 
> 
> Something is weird because packets make it to udp-ping-local which shouldn’t 
> be hit at all. Will take a look as soon as I can. 
> 
> Thanks,
> Florin
> 
> 
>> On May 21, 2019, at 3:41 PM, Nathan Skrzypczak > <mailto:nathan.skrzypc...@gmail.com>> wrote:
>> 
>> Hi vpp-devs,
>> 
>> I ran into an issue while running VCL hoststack tests on master
>> make test-debug 
>> TEST=test_vcl.VCLIpv6ThruHostStackEcho.test_vcl_ipv6_thru_host_stack_echo 
>> fails on an assert (trace below), but running make test TEST=... passes as 
>> asserts are disabled in release mode.
>> 
>> (1) Concerning the test infra, as far as I understand, jenkins only runs 
>> test in release mode (the reason why this issue got through). So shouldn’t 
>> enable debug while running tests ?
>> 
>> (2) Concerning this specific issue :
>> 
>> Reverting f8d50682cd <https://gerrit.fd.io/r/#/c/19623/> seems to resolve 
>> it, but I don’t think it caused it in the first place.
>> What happens is that on udp_ping_node.c:612 we set the local next node index 
>> for udp-ping-local to lm->local_next_by_ip_protocol[hbh0->protocol] which is 
>> a local next node index for the ip6-local-node. So it breaks the assert
>> We can add a udp-ping-local node registration in the ip6_register_protocol 
>> function (but that’s quite ugly)
>> We could also register all ip6-local-node nodes into udp-ping-local but that 
>> would require knowing when they’re all registered
>> My setup is ubuntu18.04.1 on x86_64
>> 
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>> #1  0x7f88365db801 in __GI_abort () at abort.c:79
>> #2  0x556bc57c87cd in os_panic () at 
>> /usr/share/vpp/src/vpp/vnet/main.c:355
>> #3  0x7f88369c2020 in debugger () at 
>> /usr/share/vpp/src/vppinfra/error.c:84
>> #4  0x7f88369c245b in _clib_error (how_to_die=2, function_name=0x0, 
>> line_number=0, fmt=0x7f8836fcf538 "%s:%d (%s) assertion `%s' fails")
>> at /usr/share/vpp/src/vppinfra/error.c:143
>> #5  0x7f8836f46154 in vlib_node_runtime_get_next_frame 
>> (vm=0x7f88371f2c80 , n=0x7f87f66cd580, next_index=7) at 
>> /usr/share/vpp/src/vlib/node_funcs.h:300
>> #6  0x7f8836f48081 in vlib_get_next_frame_internal (vm=0x7f88371f2c80 
>> , node=0x7f87f66cd580, next_index=7, 
>> allocate_new_next_frame=0)
>> at /usr/share/vpp/src/vlib/main.c:371
>> #7  0x7f87f2c5ecec in udp_ping_local_node_fn (vm=0x7f88371f2c80 
>> , node=0x7f87f66cd580, frame=0x7f87f70cc2c0)
>> at /usr/share/vpp/src/plugins/ioam/udp-ping/udp_ping_node.c:782
>> #8  0x7f8836f4b9b5 in dispatch_node (vm=0x7f88371f2c80 
>> , node=0x7f87f66cd580, type=VLIB_NODE_TYPE_INTERNAL, 
>> dispatch_state=VLIB_NODE_STATE_POLLING,
>> frame=0x7f87f70cc2c0, last_time_stamp=734672943877552) at 
>> /usr/share/vpp/src/vlib/main.c:1213
>> #9  0x7f8836f4c190 in dispatch_pending_node (vm=0x7f88371f2c80 
>> , pending_frame_index=23, last_time_stamp=734672943877552)
>> at /usr/share/vpp/src/vlib/main.c:1381
>> #10 0x7f8836f4debc in vlib_main_or_worker_loop (vm=0x7f88371f2c80 
>> , is_main=1) at /usr/share/vpp/src/vlib/main.c:1825
>> #11 0x7f8836f4e737 in vlib_main_loop (vm=0x7f88371f2c80 
>> ) at /usr/share/vpp/src/vlib/main.c:1927
>> #12 0x7f8836f4f4ab in vlib_main (vm=0x7f88371f2c80 , 
>> input=0x7f87f616dfb0) at /usr/share/vpp/src/vlib/main.c:2116
>> #13 0x7f8836fbbf57 in thread0 (arg=140223017069696) at 
>> /usr/share/vpp/src/vlib/unix/main.c:640
>> #14 0x7f88369e5304 in clib_calljmp () from 
>> /usr/share/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.04
>> #15 0x7ffd530aa390 in ?? ()
>

Re: [vpp-dev] VCL hoststack test & asserts

2019-05-22 Thread Florin Coras
Hi Nathan, 

Just a quick reply. I regularly run make test-debug TEST=vcl so please continue 
to do that and please report any issues you may encounter. 

Something is weird because packets make it to udp-ping-local which shouldn’t be 
hit at all. Will take a look as soon as I can. 

Thanks,
Florin


> On May 21, 2019, at 3:41 PM, Nathan Skrzypczak  
> wrote:
> 
> Hi vpp-devs,
> 
> I ran into an issue while running VCL hoststack tests on master
> make test-debug 
> TEST=test_vcl.VCLIpv6ThruHostStackEcho.test_vcl_ipv6_thru_host_stack_echo 
> fails on an assert (trace below), but running make test TEST=... passes as 
> asserts are disabled in release mode.
> 
> (1) Concerning the test infra, as far as I understand, jenkins only runs test 
> in release mode (the reason why this issue got through). So shouldn’t enable 
> debug while running tests ?
> 
> (2) Concerning this specific issue :
> 
> Reverting f8d50682cd  seems to resolve it, 
> but I don’t think it caused it in the first place.
> What happens is that on udp_ping_node.c:612 we set the local next node index 
> for udp-ping-local to lm->local_next_by_ip_protocol[hbh0->protocol] which is 
> a local next node index for the ip6-local-node. So it breaks the assert
> We can add a udp-ping-local node registration in the ip6_register_protocol 
> function (but that’s quite ugly)
> We could also register all ip6-local-node nodes into udp-ping-local but that 
> would require knowing when they’re all registered
> My setup is ubuntu18.04.1 on x86_64
> 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f88365db801 in __GI_abort () at abort.c:79
> #2  0x556bc57c87cd in os_panic () at 
> /usr/share/vpp/src/vpp/vnet/main.c:355
> #3  0x7f88369c2020 in debugger () at 
> /usr/share/vpp/src/vppinfra/error.c:84
> #4  0x7f88369c245b in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x7f8836fcf538 "%s:%d (%s) assertion `%s' fails")
> at /usr/share/vpp/src/vppinfra/error.c:143
> #5  0x7f8836f46154 in vlib_node_runtime_get_next_frame (vm=0x7f88371f2c80 
> , n=0x7f87f66cd580, next_index=7) at 
> /usr/share/vpp/src/vlib/node_funcs.h:300
> #6  0x7f8836f48081 in vlib_get_next_frame_internal (vm=0x7f88371f2c80 
> , node=0x7f87f66cd580, next_index=7, 
> allocate_new_next_frame=0)
> at /usr/share/vpp/src/vlib/main.c:371
> #7  0x7f87f2c5ecec in udp_ping_local_node_fn (vm=0x7f88371f2c80 
> , node=0x7f87f66cd580, frame=0x7f87f70cc2c0)
> at /usr/share/vpp/src/plugins/ioam/udp-ping/udp_ping_node.c:782
> #8  0x7f8836f4b9b5 in dispatch_node (vm=0x7f88371f2c80 
> , node=0x7f87f66cd580, type=VLIB_NODE_TYPE_INTERNAL, 
> dispatch_state=VLIB_NODE_STATE_POLLING,
> frame=0x7f87f70cc2c0, last_time_stamp=734672943877552) at 
> /usr/share/vpp/src/vlib/main.c:1213
> #9  0x7f8836f4c190 in dispatch_pending_node (vm=0x7f88371f2c80 
> , pending_frame_index=23, last_time_stamp=734672943877552)
> at /usr/share/vpp/src/vlib/main.c:1381
> #10 0x7f8836f4debc in vlib_main_or_worker_loop (vm=0x7f88371f2c80 
> , is_main=1) at /usr/share/vpp/src/vlib/main.c:1825
> #11 0x7f8836f4e737 in vlib_main_loop (vm=0x7f88371f2c80 
> ) at /usr/share/vpp/src/vlib/main.c:1927
> #12 0x7f8836f4f4ab in vlib_main (vm=0x7f88371f2c80 , 
> input=0x7f87f616dfb0) at /usr/share/vpp/src/vlib/main.c:2116
> #13 0x7f8836fbbf57 in thread0 (arg=140223017069696) at 
> /usr/share/vpp/src/vlib/unix/main.c:640
> #14 0x7f88369e5304 in clib_calljmp () from 
> /usr/share/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.04
> #15 0x7ffd530aa390 in ?? ()
> #16 0x7f8836fbc513 in vlib_unix_main (argc=56, argv=0x7ffd530ab6a8) at 
> /usr/share/vpp/src/vlib/unix/main.c:710
> #17 0x556bc57c7fd0 in main (argc=56, argv=0x7ffd530ab6a8) at 
> /usr/share/vpp/src/vpp/vnet/main.c:280
> Thanks a lot in advance
> 
> Cheers
> 
> -Nathan
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13104): https://lists.fd.io/g/vpp-dev/message/13104
> Mute This Topic: https://lists.fd.io/mt/31696737/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13112): https://lists.fd.io/g/vpp-dev/message/13112
Mute This Topic: https://lists.fd.io/mt/31696737/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] build error in VPP master branch

2019-05-16 Thread Florin Coras
Did you try make wipe/wipe-release?

Florin

> On May 16, 2019, at 7:45 PM, Zhiyong Yang  wrote:
> 
> Hi guys,
>  
> Does anybody run into the trouble as below? How to fix it? 
> fatal error: quicly/defaults.h: No such file or directory
>  
> thanks
> Zhiyong
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13073): https://lists.fd.io/g/vpp-dev/message/13073 
> 
> Mute This Topic: https://lists.fd.io/mt/31651127/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13074): https://lists.fd.io/g/vpp-dev/message/13074
Mute This Topic: https://lists.fd.io/mt/31651127/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] finding a virtual memory leak in VPP

2019-05-09 Thread Florin Coras
Hi Andreas, 

Maybe you allocate a lot of shared memory segments for UPF? I seem to remember 
you were using the host stack, are you using it in this test?

Florin

> On May 9, 2019, at 9:17 AM, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> Something in VPP (most likely my UPF/GTP plugin) is causing an abnormal high 
> virtual memory consumption. `show memory` without and with memory-trace 
> enable can not explain it.
> 
> With some 10k sessions I see as much as 1TB virtual memory usage, but only 
> about 200MB or so residential memory. `show memory` also only reports about 
> 200MB.
> 
> My best guess is that something requests virtual memory pages from the OS and 
> does not return them.
> Any hint on how to track this down? What in VPP could request that much 
> virtual memory without actually using it?
> 
> Many thanks
> Andreas
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12970): https://lists.fd.io/g/vpp-dev/message/12970
> Mute This Topic: https://lists.fd.io/mt/31557024/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] how to trace tcp4-output?

2019-04-29 Thread Florin Coras
Sure, that’s a good option. But, the point is that the stack won’t try to 
figure out if the output interface is actually capable of honoring the 
“offload” flag. Still need to think if this could be handled better.

Also, note that the stack handles segmentation itself, it does not offload 
rx/tx re-assembly/segmentation. 

Florin

> On Apr 29, 2019, at 9:38 AM, Andreas Schultz  
> wrote:
> 
> Am Mo., 29. Apr. 2019 um 18:21 Uhr schrieb Florin Coras 
> mailto:fcoras.li...@gmail.com>>:
> Unfortunately, as things stand, the tunnel should compute the checksum before 
> encapsulating the traffic. Otherwise the output node won’t be able to find 
> the right headers. 
> 
> Will look into simplifying this. 
> 
> I have look into it a bit more. If I had used a midchain-adjacency instead it 
> should would. The midchain rewrite processing seems be handling the check 
> sums and also segmentation.
> 
> Andreas
> 
> 
> Florin
> 
>> On Apr 29, 2019, at 8:18 AM, Andreas Schultz > <mailto:andreas.schu...@travelping.com>> wrote:
>> 
>> Thanks, that helped a lot. I found that traffic is not passing through the 
>> node as I expected it.
>> 
>> The actual graph is
>> 
>>tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input
>> 
>> Note: upf-if-input is the node function of an interface. It is found through 
>> a fib entry that look like this:
>> 
>> 10.106.14.227/32 <http://10.106.14.227/32>
>>   unicast-ip4-chain
>>   [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
>> [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000
>> 
>> What I was expecting that between ip4-rewrite and upf-if-input the 
>> vnet_interface_output_node function of the software interface would be 
>> invoked.
>> 
>> As far as I can see that is the only logical place that would calculate 
>> check sums and do segmentation on for software interfaces.
>> For routed traffic that is normally not needed, but locally generated 
>> traffic (like a local TCP endpoint) needs it.
>> 
>> It feels like I'm missing a important piece of the picture here.
>> What function or node should fill in the checksum for locally generate 
>> traffic before it is encapsulated into a tunnel and what might be wrong that 
>> it does not work in my setup?
>> 
>> Many Thanks,
>> Andreas
>> 
>> Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) 
>> mailto:dbar...@cisco.com>>:
>> Try “pcap dispatch trace on max 1 buffer-trace  
>> 1000”, cause a transaction, “pcap dispatch trace off”; then look at the 
>> resulting trace w/ a vpp-dispatch-trace enabled wireshark. See 
>> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>>  
>> <https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html>
>>  
>> 
>> HTH... Dave
>> 
>>  
>> 
>>  
>> 
>> From: mailto:vpp-dev@lists.fd.io>> on behalf of 
>> Andreas Schultz > <mailto:andreas.schu...@travelping.com>>
>> Date: Monday, April 29, 2019 at 9:31 AM
>> To: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" > <mailto:vpp-dev@lists.fd.io>>
>> Subject: [vpp-dev] how to trace tcp4-output?
>> 
>>  
>> 
>> Hi, 
>> 
>>  
>> 
>> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
>> 
>>  
>> 
>> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
>> not producing the expected result. The trace buffer is always empty.
>> 
>>  
>> 
>> I was expecting that "trace add af-packet-input 100" would also trace the 
>> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
>> the tcp4-output nodes are not showing up in the trace.
>> 
>> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
>> after it has gone through an encapsulation.
>> 
>>  
>> 
>> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
>> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
>> suspect there is something going on with the csum offload. But without the 
>> trace, finding that problem is a nightmare.
>> 
>>  
>> 
>> Many thanks,
>> 
>> Andreas
>> 
>>  
>> 
>>  
>> 
>> -- 
>> 
>> -- 
>> Dipl.-Inform. Andreas Schultz
>> 
>> --- enabling your networks -

Re: [vpp-dev] how to trace tcp4-output?

2019-04-29 Thread Florin Coras
Unfortunately, as things stand, the tunnel should compute the checksum before 
encapsulating the traffic. Otherwise the output node won’t be able to find the 
right headers. 

Will look into simplifying this. 

Florin

> On Apr 29, 2019, at 8:18 AM, Andreas Schultz  
> wrote:
> 
> Thanks, that helped a lot. I found that traffic is not passing through the 
> node as I expected it.
> 
> The actual graph is
> 
>tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input
> 
> Note: upf-if-input is the node function of an interface. It is found through 
> a fib entry that look like this:
> 
> 10.106.14.227/32 
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]]
> [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000
> 
> What I was expecting that between ip4-rewrite and upf-if-input the 
> vnet_interface_output_node function of the software interface would be 
> invoked.
> 
> As far as I can see that is the only logical place that would calculate check 
> sums and do segmentation on for software interfaces.
> For routed traffic that is normally not needed, but locally generated traffic 
> (like a local TCP endpoint) needs it.
> 
> It feels like I'm missing a important piece of the picture here.
> What function or node should fill in the checksum for locally generate 
> traffic before it is encapsulated into a tunnel and what might be wrong that 
> it does not work in my setup?
> 
> Many Thanks,
> Andreas
> 
> Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) 
> mailto:dbar...@cisco.com>>:
> Try “pcap dispatch trace on max 1 buffer-trace  
> 1000”, cause a transaction, “pcap dispatch trace off”; then look at the 
> resulting trace w/ a vpp-dispatch-trace enabled wireshark. See 
> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html
>  
> 
>  
> 
> HTH... Dave
> 
>  
> 
>  
> 
> From: mailto:vpp-dev@lists.fd.io>> on behalf of Andreas 
> Schultz  >
> Date: Monday, April 29, 2019 at 9:31 AM
> To: "vpp-dev@lists.fd.io "  >
> Subject: [vpp-dev] how to trace tcp4-output?
> 
>  
> 
> Hi, 
> 
>  
> 
> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
> 
>  
> 
> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
> not producing the expected result. The trace buffer is always empty.
> 
>  
> 
> I was expecting that "trace add af-packet-input 100" would also trace the 
> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
> the tcp4-output nodes are not showing up in the trace.
> 
> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
> after it has gone through an encapsulation.
> 
>  
> 
> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
> suspect there is something going on with the csum offload. But without the 
> trace, finding that problem is a nightmare.
> 
>  
> 
> Many thanks,
> 
> Andreas
> 
>  
> 
>  
> 
> -- 
> 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> 
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> 
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12873): https://lists.fd.io/g/vpp-dev/message/12873 
> 
> Mute This Topic: https://lists.fd.io/mt/31383412/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 

Re: [vpp-dev] how to trace tcp4-output?

2019-04-29 Thread Florin Coras
Hi Andreas, 

The tracing should work but because we’re reusing the syn packet to build the 
syn-ack, it might not show correctly. Could you breakpoint the tcp4-output and 
try to see if the trace code is hit?

As for the checksum, tcp only tags the packet with a request to have it 
offloaded. If the nic wrongly advertises that it can do it, the offload 
infrastructure will comply with that. 

If you’re using dpdk and you want to force sw checksum computation, change 
startup conf and add "dpdk { enable-tcp-udp-checksum }”.

Hope this helps,
Florin 

> On Apr 29, 2019, at 6:31 AM, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> I'm trying to debug a problem and need to trace tcp4-output with vpp 19.04.
> 
> So far I have tried it with "trace add tcp4-output 100 verbose", but that is 
> not producing the expected result. The trace buffer is always empty.
> 
> I was expecting that "trace add af-packet-input 100" would also trace the 
> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and 
> the tcp4-output nodes are not showing up in the trace.
> I do know that the SYN+ACK gets generate, because I can see it in tcpdump 
> after it has gone through an encapsulation.
> 
> The problem I'm trying to figure out is why the TCP SYN+ACK packet when it 
> hits a tunnel encapsulation node has invalid (or even no) check sums. I 
> suspect there is something going on with the csum offload. But without the 
> trace, finding that problem is a nightmare.
> 
> Many thanks,
> Andreas
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12869): https://lists.fd.io/g/vpp-dev/message/12869
> Mute This Topic: https://lists.fd.io/mt/31383412/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12872): https://lists.fd.io/g/vpp-dev/message/12872
Mute This Topic: https://lists.fd.io/mt/31383412/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] [csit-dev] VPP 19.04 Release is complete!

2019-04-24 Thread Florin Coras
Awesome! Thanks for managing this one, Dave!

Cheers, 
Florin

> On Apr 24, 2019, at 3:06 PM, Dave Wallace  wrote:
> 
> Folks,
> 
> I am pleased to announce that the VPP 19.04 Release is complete and the 
> release artifacts are available on 
> PackageCloud:https://packagecloud.io/fdio/release 
> 
> 
> Many thanks to all of the VPP & CSIT contributors and extended FD.io 
> community members who helped make this another successful VPP release.
> 
> Cheers,
> -daw-
> "Your Friendly VPP 19.04 Release Manager"
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#3460): https://lists.fd.io/g/csit-dev/message/3460
> Mute This Topic: https://lists.fd.io/mt/31336638/675152
> Group Owner: csit-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/csit-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12850): https://lists.fd.io/g/vpp-dev/message/12850
Mute This Topic: https://lists.fd.io/mt/31336691/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] VCL, ld-preload and VPP shared memory better understanding

2019-04-22 Thread Florin Coras
Hi Ido, 

You can find some high level documentation about vcl here [1]. In particular, 
check the presentations at the bottom of the page and [2]. For more details, 
you’ll have to read the code. If you need to exercise vcl, you may want to try 
using iperf [3] or the the vcl test server/client apps (see make test example 
here [4]). 

Additionally, LDP is a shim layer that intercepts syscalls and indirectly 
injects them into vcl. Because, vcl does not allow sharing of sessions between 
multiple app threads/workers/processes, ldp actually injects the requests into 
vls (vcl locked sessions) which grabs a number of locks before re-injecting 
them into vcl. Out of these 3 layers, only vcl is aware of the shared memory 
infrastructure. 

Regarding your project, although interesting, note that transports, like tcp, 
depend on the svm fifo for out of order segment reception and for buffering 
segments not yet acknowledged. Therefore, if you plan to replace the svm infra, 
you’ll need to replicate that functionality. 

Hope this helps, 
Florin

[1] https://wiki.fd.io/view/VPP/HostStack 

[2] https://wiki.fd.io/view/VPP/HostStack/SessionLayerArchitecture 

[3] https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 

[4] https://git.fd.io/vpp/tree/test/test_vcl.py 


> On Apr 22, 2019, at 6:46 AM, id...@campus.technion.ac.il wrote:
> 
> Hi all,
> 
> In part of academic project we would like to replace the shared memory 
> mechanism between the VCL and the VPP with RDMA...
> I tried to review the code in folders src/vcl and src/vlibmemory and even to 
> run the socket_test.sh demo for better understanding but it doesn't help me...
> 
>  
> where can I find a document or a video that describes better the flows of 
> messages and what functions are called between VCL and VPP 
> -- 
> 
> Best regards,
> Ido
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12829): https://lists.fd.io/g/vpp-dev/message/12829
> Mute This Topic: https://lists.fd.io/mt/31273974/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP 19.04 centos7 RPM package dependency errors

2019-04-11 Thread Florin Coras
We do have it as a dependency because we want to make sure the plugin still 
builds. However, given that most of those who use tls use the openssl engine, 
we might consider not having mbedtls as a dependency for the packages that we 
push to packagecloud ...

On a separate note, what centos do we run in the container? It seems that even 
python3 has some dependency errors. I guess that once we align the vagrant 
version with it, things should just work.

Florin

> On Apr 11, 2019, at 1:55 PM, Ed Kern (ejk)  wrote:
> 
> 
> 
>> On Apr 11, 2019, at 2:22 PM, Florin Coras > <mailto:fcoras.li...@gmail.com>> wrote:
>> 
>> Are we building rpms on a host that has mbedtls installed? 
> 
> Yes the centos container has mbedtls installed….has for quite some time since 
> it is a listed
> prerequisite straight out of the Makefile.
> 
> Ed
> 
> 
> 
> 
>> Just uninstalling it should disable the tlsmbedtls plugin, which is what we 
>> pretty much want. 
>> 
>> Florin 
>> 
>>> On Apr 11, 2019, at 1:00 PM, Dave Wallace >> <mailto:dwallac...@gmail.com>> wrote:
>>> 
>>> Tom/Billy,
>>> 
>>> Do you know what the current status is with the VPP rpm's on master/19.04?
>>> 
>>> I'm trying to install the VPP 19.04 packages from packagecloud.io 
>>> <http://packagecloud.io/> on a centos7 Vagrant/virtualbox VM (using 
>>> .../vpp/extras/vagrant/Vagrantfile) to verify that the packages are 
>>> correct.  The 19.01 packages install fine, but the 19.04 and master 
>>> packages fail with the following dependency errors:
>>> 
>>> --> Finished Dependency Resolution
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedtls.so.10()(64bit)
>>> Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: /usr/bin/python3
>>> Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: /usr/bin/python3
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedx509.so.0()(64bit)
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedcrypto.so.2()(64bit)
>>>  You could try using --skip-broken to work around the problem
>>>  You could try running: rpm -Va --nofiles --nodigest
>>> 
>>> Thanks,
>>> -daw-
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768 
>>> <https://lists.fd.io/g/vpp-dev/message/12768>
>>> Mute This Topic: https://lists.fd.io/mt/31034762/675152 
>>> <https://lists.fd.io/mt/31034762/675152>
>>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
>>> <mailto:fcoras.li...@gmail.com>]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769 
>> <https://lists.fd.io/g/vpp-dev/message/12769>
>> Mute This Topic: https://lists.fd.io/mt/31034762/675649 
>> <https://lists.fd.io/mt/31034762/675649>
>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>> <https://lists.fd.io/g/vpp-dev/unsub>  [e...@cisco.com 
>> <mailto:e...@cisco.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP 19.04 centos7 RPM package dependency errors

2019-04-11 Thread Florin Coras
Are we building rpms on a host that has mbedtls installed? Just uninstalling it 
should disable the tlsmbedtls plugin, which is what we pretty much want. 

Florin 

> On Apr 11, 2019, at 1:00 PM, Dave Wallace  wrote:
> 
> Tom/Billy,
> 
> Do you know what the current status is with the VPP rpm's on master/19.04?
> 
> I'm trying to install the VPP 19.04 packages from packagecloud.io on a 
> centos7 Vagrant/virtualbox VM (using .../vpp/extras/vagrant/Vagrantfile) to 
> verify that the packages are correct.  The 19.01 packages install fine, but 
> the 19.04 and master packages fail with the following dependency errors:
> 
> --> Finished Dependency Resolution
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedtls.so.10()(64bit)
> Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedx509.so.0()(64bit)
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedcrypto.so.2()(64bit)
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> Thanks,
> -daw-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768
> Mute This Topic: https://lists.fd.io/mt/31034762/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769
Mute This Topic: https://lists.fd.io/mt/31034762/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] Packet with custom ip-proto value drops in ip4-local node

2019-04-11 Thread Florin Coras
Hi Satish, 

From the error counters lower, it seems that ip local is not the one to drop 
the packets. Also, if the packet is not tcp or udp, checksum should not 
computed, as per ip4_local_check_l4_csum [1]. Also, packets that fail the 
source ip check should be dropped with IP4_ERROR_SPOOFED_LOCAL_PACKETS or 
IP4_ERROR_SRC_LOOKUP_MISS. 

So, to clear this up, could you attach gdb to your vpp (preferably compiled 
with debug symbols), breakpoint ip4_local_set_next_and_error and figure out if 
next for your packets is set correctly?

Hope this helps,
Florin

[1] Note that I’m using master code as a reference not 18.10 code


> On Apr 11, 2019, at 8:04 AM, satish.gu...@gmail.com wrote:
> 
> Hi VPP-Dev,
>  
> We recently moved to 1810 from 1801 and found the following issue.
> Is this a known issue (or) any help on whats happening here ?
>  
> 1. We are using memif in IP mode.
> 2. Some Control plane process sends message over MEMIF to VPP process ( memif 
> mode = IP )
> 3. We are using a custom ip-proto value of 222 and tapping these packets in a 
> separate graph node on VPP side.
> 4. This has been working fine till 1801.
> 5. When we moved to 1810, the packet is getting dropped in ip4-local with 
> reason as "blackholed packets"
> 6. When we looked at the code, this drop can happen in the following reasons
>  - SRC-IP invalid
>  - TCP/UDP checksum wrong
>  
> 7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the 
> reason
> 8. We are suspecting that this drop is due to TCP/UDP csum.
>  
> But, when the ip-proto is non-UDP-TCP, ideally this packet should have gone 
> to the next layer bypassing all these checks.
>  
> Following is the packet trace / show output and fib details
>  
> ===
> ##) 
> vpp# show node counters
>CountNode  Reason
>  2null-node   blackholed packets
>  
> ##)
> vpp# show trace
>  
> Packet 1
>  
> 00:48:08:119264: memif-input
>   memif: hw_if_index 3 next-index 0
> slot: ring 0
> 00:48:08:119354: ip4-input-no-checksum
>   unknown 222: 192.168.1.2 -> 192.168.1.1
> tos 0x00, ttl 64, length 10020, checksum 0xcfbe
> fragment id 0x
> 00:48:08:120320: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   unknown 222: 192.168.1.2 -> 192.168.1.1
> tos 0x00, ttl 64, length 10020, checksum 0xcfbe
> fragment id 0x
> 00:48:08:120331: ip4-local
> unknown 222: 192.168.1.2 -> 192.168.1.1
>   tos 0x00, ttl 64, length 10020, checksum 0xcfbe
>   fragment id 0x
>  
> ##)
>  
> vpp# show ip fib
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
> locks:[src:plugin-hi:2, src:default-route:1, ]
> 192.168.1.0/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
> [0] [@0]: dpo-drop ip4
> 192.168.1.0/24
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]
> [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000
> 192.168.1.1/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]]
> [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0
> 192.168.1.255/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
> [0] [@0]: dpo-drop ip4
>  
> 
>  
> Also, is there anyway to get the exact sub-error-code which indicates that 
> this is due to TCP/UDP checksum error etc ?
> Appreciate any inputs in this regard.
>  
> Thanks & Regards,
> Satish
>  
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12765): https://lists.fd.io/g/vpp-dev/message/12765
> Mute This Topic: https://lists.fd.io/mt/31031696/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12766): https://lists.fd.io/g/vpp-dev/message/12766
Mute This Topic: https://lists.fd.io/mt/31031696/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] multi-threaded application, "epoll_wait" and "epoll_ctl" have "received signal SIGABRT, Aborted".

2019-03-30 Thread Florin Coras
Hi Sarath, 


> On Mar 29, 2019, at 8:47 PM, Sharath Kumar 
>  wrote:
> 
> Hi Florin, 
> 
> The patch doesn't fix any of the issues with epoll/select.
> 
> The usecase is like below
> 1.Main thread calls epoll_create.
> 2.One of the non-main threads calls epoll_ctl.
> 3.And another non-main thread calls epoll_wait.
> 
> All the 3 threads above operate on a single epoll fd.
> 
> Is this usecase supported? 

No, that usecase is not supported. 

> 
> How to register these non-main threads [2 and 3] as workers with vcl?
> I am a newbie to VPP, I have no idea about this. Can you give me some input 
> on this?
> 
> Would registering these non-main threads [2,3] as workers with vcl resolve my 
> problem? 
> Did you mean LDP doesn't support this kind of registration? 

There are several layers that help integrating applications with vpp’s host 
stack:
- VCL(VPPCOM library): it facilitates the interaction with the session layer in 
vpp by exposing a set of apis that are similar to POSIX socket apis. That means 
applications don’t have to interact with vpp’s binary api, don’t have to 
directly work with shared memory fifos and more importantly they get implicit 
support for async communication mechanisms like epoll/select. For performance 
reasons, VCL avoids as much as possible locking. As as result, it doesn’t allow 
sharing of sessions (or session handles/fds from app perspective) between app 
threads or processes (in case the apps fork). However, if they need more 
workers for performance reasons, applications can register their worker threads 
with vcl (see vppcom_worker_register). Sessions cannot be shared between 
workers but each worker can have its own epoll/select loop. 
- VLS (VCL locked sessions): as the name suggests, it employs a set of locks 
that allow: 1) multi threaded apps that have one dispatcher thread and N 
‘worker’ threads to transparently work with vcl. In this scenario, vcl “sees” 
only one worker. Expectation is that only the dispatcher thread (main thread) 
interacts with epoll/select. 2) multi-process apps to work with vcl, but for 
that it employs additional logic when applications fork. Every child/forked 
process is registered with vcl by vls, so vcl sees more workers. 
- LDP (LD_PRELOAD): this is a shim that intercepts network related syscalls and 
redirects them into vls. Its goal is to have applications work unchanged with 
vpp's host stack. Since there are no POSIX apis for registering workers with 
the kernel, ldp cannot register app workers with vls/vcl. 

As far as I can tell, you’re running ldp through dmm. Thus, to support your 
usecase, you’d probably have to change your app to directly work with vls or 
vcl. 

Hope this helps, 
Florin

> 
> Thanks, 
> Sharath. 
> 
> 
> On Sat 30 Mar, 2019, 1:27 AM Florin Coras,  <mailto:fcoras.li...@gmail.com>> wrote:
> Just so I understand, does the patch not fix the epoll issues or does it fix 
> the issues but it doesn’t fix select, which apparently crashes in a different 
> way. 
> 
> Second, what is your usecase/app? Are you actually trying to share 
> epoll/select between multiple threads? That is, multiple threads might want 
> to call epoll_wait/select at the same time? That is not supported. The 
> implicit assumption is that only the dispatcher thread is to call the two 
> functions the rest of the threads do only io work. 
> 
> If all the threads must handle async communication via epoll/select, then 
> they should register themselves as workers with vcl and get their own epoll 
> fd. LDP does not support that. 
> 
> Florin
> 
>> On Mar 29, 2019, at 12:13 PM, Sharath Kumar 
>> > <mailto:sharathkumarboyanapa...@gmail.com>> wrote:
>> 
>> No, it doesn't work. 
>> 
>> Attaching the applications being used.
>> 
>> "Select" also has similar kind of issue when called from non-main thread
>> 
>> Thread 9 "nstack_select" received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fffd77fe700 (LWP 63170)]
>> 0x74e1d032 in ldp_select_init_maps (original=0x7fffbc0008c0, 
>> resultb=0x7fffe002e514, libcb=0x7fffe002e544, vclb=0x7fffe002e52c, nfds=34, 
>> minbits=64, n_bytes=5, si_bits=0x7fffd77fdc20, 
>> libc_bits=0x7fffd77fdc28) at 
>> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:601
>> 601clib_bitmap_validate (*vclb, minbits);
>> (gdb) bt
>> #0  0x74e1d032 in ldp_select_init_maps (original=0x7fffbc0008c0, 
>> resultb=0x7fffe002e514, libcb=0x7fffe002e544, vclb=0x7fffe002e52c, nfds=34, 
>> minbits=64, n_bytes=5, si_bits=0x7fffd77fdc20, 
>> libc_bits=0x7fffd77fdc28) at 
>> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:601
>> #1  0x

Re: [vpp-dev] multi-threaded application, "epoll_wait" and "epoll_ctl" have "received signal SIGABRT, Aborted".

2019-03-29 Thread Florin Coras
Just so I understand, does the patch not fix the epoll issues or does it fix 
the issues but it doesn’t fix select, which apparently crashes in a different 
way. 

Second, what is your usecase/app? Are you actually trying to share epoll/select 
between multiple threads? That is, multiple threads might want to call 
epoll_wait/select at the same time? That is not supported. The implicit 
assumption is that only the dispatcher thread is to call the two functions the 
rest of the threads do only io work. 

If all the threads must handle async communication via epoll/select, then they 
should register themselves as workers with vcl and get their own epoll fd. LDP 
does not support that. 

Florin

> On Mar 29, 2019, at 12:13 PM, Sharath Kumar 
>  wrote:
> 
> No, it doesn't work. 
> 
> Attaching the applications being used.
> 
> "Select" also has similar kind of issue when called from non-main thread
> 
> Thread 9 "nstack_select" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffd77fe700 (LWP 63170)]
> 0x74e1d032 in ldp_select_init_maps (original=0x7fffbc0008c0, 
> resultb=0x7fffe002e514, libcb=0x7fffe002e544, vclb=0x7fffe002e52c, nfds=34, 
> minbits=64, n_bytes=5, si_bits=0x7fffd77fdc20, 
> libc_bits=0x7fffd77fdc28) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:601
> 601 clib_bitmap_validate (*vclb, minbits);
> (gdb) bt
> #0  0x74e1d032 in ldp_select_init_maps (original=0x7fffbc0008c0, 
> resultb=0x7fffe002e514, libcb=0x7fffe002e544, vclb=0x7fffe002e52c, nfds=34, 
> minbits=64, n_bytes=5, si_bits=0x7fffd77fdc20, 
> libc_bits=0x7fffd77fdc28) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:601
> #1  0x74e1db47 in ldp_pselect (nfds=34, readfds=0x7fffbc0008c0, 
> writefds=0x7fffbc000cd0, exceptfds=0x7fffbc0010e0, timeout=0x7fffd77fdcb0, 
> sigmask=0x0)
> at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:723
> #2  0x74e1e5d5 in select (nfds=34, readfds=0x7fffbc0008c0, 
> writefds=0x7fffbc000cd0, exceptfds=0x7fffbc0010e0, timeout=0x7fffd77fdd20)
> at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:857
> #3  0x77b4c42a in nstack_select_thread (arg=0x0) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/src/nSocket/nstack/event/select/nstack_select.c:651
> #4  0x778ed6ba in start_thread (arg=0x7fffd77fe700) at 
> pthread_create.c:333
> #5  0x7741b41d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> 
> 
> Before https://gerrit.fd.io/r/#/c/18597/ <https://gerrit.fd.io/r/#/c/18597/> 
> I have tried to fix the issue.
> 
> The below changes fixed epoll_wait and epoll_ctl issues for me.[doesn't 
> include the changes of https://gerrit.fd.io/r/#/c/18597/ 
> <https://gerrit.fd.io/r/#/c/18597/>]
> 
> diff --git a/src/vcl/vcl_locked.c b/src/vcl/vcl_locked.c
> index fb19b5d..e6c891b 100644
> --- a/src/vcl/vcl_locked.c
> +++ b/src/vcl/vcl_locked.c
> @@ -564,7 +564,10 @@ vls_attr (vls_handle_t vlsh, uint32_t op, void *buffer, 
> uint32_t * buflen)
>  
>if (!(vls = vls_get_w_dlock (vlsh)))
>  return VPPCOM_EBADFD;
> +
> +  vls_mt_guard (0, VLS_MT_OP_XPOLL);
>rv = vppcom_session_attr (vls_to_sh_tu (vls), op, buffer, buflen);
> +  vls_mt_unguard ();
>vls_get_and_unlock (vlsh);
>return rv;
>  }
> @@ -773,8 +776,10 @@ vls_epoll_ctl (vls_handle_t ep_vlsh, int op, 
> vls_handle_t vlsh,
>vls_table_rlock ();
>ep_vls = vls_get_and_lock (ep_vlsh);
>vls = vls_get_and_lock (vlsh);
> +  vls_mt_guard (0, VLS_MT_OP_XPOLL);
>    ep_sh = vls_to_sh (ep_vls);
>sh = vls_to_sh (vls);
> +  vls_mt_unguard ();
>  
>if (PREDICT_FALSE (!vlsl->epoll_mp_check))
>  vls_epoll_ctl_mp_checks (vls, op);
> 
> Thanks,
> Sharath.
> 
> On Fri, Mar 29, 2019 at 9:15 PM Florin Coras  <mailto:fcoras.li...@gmail.com>> wrote:
> Interesting. What application are you running and does this [1] fix the issue 
> for you?
> 
> In short, many of vls’ apis check if the call is coming in on a new pthread 
> and program vcl accordingly if yes. The patch makes sure vls_attr does that 
> as well.
> 
> Thanks, 
> Florin
> 
> [1] https://gerrit.fd.io/r/#/c/18597/ <https://gerrit.fd.io/r/#/c/18597/>
> 
>> On Mar 29, 2019, at 4:29 AM, Dave Barach via Lists.Fd.Io 
>> <http://lists.fd.io/> > <mailto:dbarach=cisco@lists.fd.io>> wrote:
>> 
>> For whatever reason, the vls layer received an event notification which 
>> didn’t end well. vcl_worker_get (wrk_index=4294967295) [aka 0x] will 
>> never work.
>>  
>> I’ll let Florin co

Re: [vpp-dev] multi-threaded application, "epoll_wait" and "epoll_ctl" have "received signal SIGABRT, Aborted".

2019-03-29 Thread Florin Coras
Interesting. What application are you running and does this [1] fix the issue 
for you?

In short, many of vls’ apis check if the call is coming in on a new pthread and 
program vcl accordingly if yes. The patch makes sure vls_attr does that as well.

Thanks, 
Florin

[1] https://gerrit.fd.io/r/#/c/18597/

> On Mar 29, 2019, at 4:29 AM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> For whatever reason, the vls layer received an event notification which 
> didn’t end well. vcl_worker_get (wrk_index=4294967295) [aka 0x] will 
> never work.
>  
> I’ll let Florin comment further. He’s in the PDT time zone, so don’t expect 
> to hear from him for a few hours.
>  
> D.
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of sharath kumar
> Sent: Friday, March 29, 2019 12:18 AM
> To: vpp-dev@lists.fd.io ; csit-...@lists.fd.io 
> 
> Subject: [vpp-dev] multi-threaded application, "epoll_wait" and "epoll_ctl" 
> have "received signal SIGABRT, Aborted".
>  
> Hello all,
>  
> I am a newbie to VPP.
>  
> I am trying to run VPP with a multi-threaded application.
> "recv" works fine from non-main threads,
> whereas "epoll_wait" and "epoll_ctl" have "received signal SIGABRT, Aborted".
>  
> Is this a known issue?
> Or am I doing something wrong?
>  
> Attaching  backtrace for  "epoll_wait" and "epoll_ctl"
>  
> Thread 9 "dmm_vcl_epoll" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffd67fe700 (LWP 56234)]
> 0x77349428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x77349428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x7734b02a in __GI_abort () at abort.c:89
> #2  0x7496d873 in os_panic () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/unix-misc.c:176
> #3  0x748ce42c in debugger () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/error.c:84
> #4  0x748ce864 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x74bfe0e0 "%s:%d (%s) assertion `%s' fails")
> at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/error.c:143
> #5  0x74bcca7d in vcl_worker_get (wrk_index=4294967295) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vcl_private.h:540
> #6  0x74bccabe in vcl_worker_get_current () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vcl_private.h:554
> #7  0x74bd7c49 in vppcom_session_attr (session_handle=4278190080, 
> op=6, buffer=0x0, buflen=0x0) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vppcom.c:2606
> #8  0x74bfc7fd in vls_attr (vlsh=0, op=6, buffer=0x0, buflen=0x0) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vcl_locked.c:569
> #9  0x74e21736 in ldp_epoll_pwait (epfd=32, events=0x7fffd67fad20, 
> maxevents=1024, timeout=100, sigmask=0x0) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:2203
> #10 0x74e21948 in epoll_wait (epfd=32, events=0x7fffd67fad20, 
> maxevents=1024, timeout=100) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/ldp.c:2257
> #11 0x74e13041 in dmm_vcl_epoll_thread (arg=0x0) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/dmm_vcl_adpt.c:75
> #12 0x778ed6ba in start_thread (arg=0x7fffd67fe700) at 
> pthread_create.c:333
> #13 0x7741b41d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>  
>  
>  
>  
> Thread 11 "vs_epoll" received signal SIGABRT, Aborted.
> 0x77349428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x77349428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x7734b02a in __GI_abort () at abort.c:89
> #2  0x7496d873 in os_panic () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/unix-misc.c:176
> #3  0x748ce42c in debugger () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/error.c:84
> #4  0x748ce864 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x74bfe1a0 "%s:%d (%s) assertion `%s' fails")
> at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vppinfra/error.c:143
> #5  0x74bcca7d in vcl_worker_get (wrk_index=4294967295) at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vcl_private.h:540
> #6  0x74bccabe in vcl_worker_get_current () at 
> /home/root1/sharath/2019/vpp_ver/19.04/dmm/stacks/vpp/vpp/src/vcl/vcl_private.h:554
> #7  

Re: [vpp-dev] New vpp project committer: Paul Vinciguerra

2019-02-28 Thread Florin Coras
Congrats, Paul!!

Florin

> On Feb 28, 2019, at 2:37 PM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> Please join me in congratulating Paul on his election as a vpp project 
> committer!
>  
> Thanks... Dave
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12394): https://lists.fd.io/g/vpp-dev/message/12394 
> 
> Mute This Topic: https://lists.fd.io/mt/30168763/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] New vpp project committer nomination: Paul Vinciguerra

2019-02-27 Thread Florin Coras
+1

Florin

> On Feb 27, 2019, at 5:20 AM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> +1... Dave
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Dave Barach via Lists.Fd.Io
> Sent: Wednesday, February 27, 2019 7:38 AM
> To: vpp-dev@lists.fd.io 
> Cc: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] New vpp project committer nomination: Paul Vinciguerra
>  
> In view of significant code contributions to the vpp project - see below - 
> I'm pleased to nominate Paul Vinciguerra as a vpp project committer. I have 
> high confidence that he'll be a major asset to the project in a committer 
> role.  
>  
> Paul has contributed 100 merged patches, concentrating on the “make test” .py 
> framework. 
> Seehttps://gerrit.fd.io/r/#/q/status:merged+owner:%22Paul+Vinciguerra+%253Cpvinci%2540vinciconsulting.com%253E%22
>  
> 
>  
> Committers, please vote (+1, 0, -1) on vpp-dev@lists.fd.io 
> . We'll need a recorded vote so that the TSC will 
> approve Paul’s nomination.
>  
> If at all possible please vote today, February 27, 2019 so we can add Paul’s 
> nomination to tomorrow’s TSC agenda for final approval.
>  
> Thanks... Dave
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12356): https://lists.fd.io/g/vpp-dev/message/12356 
> 
> Mute This Topic: https://lists.fd.io/mt/30151621/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12365): https://lists.fd.io/g/vpp-dev/message/12365
Mute This Topic: https://lists.fd.io/mt/30151621/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] iperf3 with vcl

2019-02-21 Thread Florin Coras
Yes, there is a patch [1] if you’re not running the release code already. If 
possible, switch to using top of 19.01 branch since it includes all the fixes 
for that release. 

Florin

[1]  https://gerrit.fd.io/r/#/c/16947/

> On Feb 21, 2019, at 9:41 AM, Ramaraj Pandian  wrote:
> 
> Hi Florin, Its vpp 19.01 on centos, seems like there is a patch available, I 
> will try that. Thanks.
>  
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin 
> Coras
> Sent: Thursday, February 21, 2019 8:40 AM
> To: Ramaraj Pandian 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] iperf3 with vcl
>  
> Hi Ram,
>  
> What os and what vpp version? We’re constantly running iperf3 in our CI in 
> ubuntu 18.04.
>  
> Thanks,
> Florin
> 
> 
> On Feb 20, 2019, at 6:07 PM, Ramaraj Pandian  <mailto:nr.pand...@samsung.com>> wrote:
>  
> I am trying to run iperf server and client to measure performance between two 
> vpp instances as per “https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.fd.io_view_VPP_HostStack_LDP_iperf=DwMFaQ=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2=oRHEIOpHZcsJ3cwQPnvGgpYgN-7QL1wVK1p9i5TkF1M=V1WGGx25-FFHMK9tBiwtnoorucA7awj3GnNj3nsW6PI=KIMWv40MP0x1WpxHE18Z5Vq6-18WboLxsbRG2RGRdgU=>
>  “ but I get the following error(unable to set TCP_CONGESTION) on client 
> side? Any insights into this? I would appreciate your help.
>  
> vppcom_session_close:1079: vcl<62624:0>: session handle 1 [0x3] 
> removed
> iperf3: error - unable to set TCP_CONGESTION: Supplied congestion control 
> algorithm not supported on this host
> ldp_destructor:3375: LDP<62624>: LDP destructor: done!
> vl_client_disconnect:330: queue drain: 605
> vl_client_disconnect:330: queue drain: 619
>  
> Thanks
> Ram
>  
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12306): https://lists.fd.io/g/vpp-dev/message/12306 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fd.io_g_vpp-2Ddev_message_12306=DwMFaQ=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2=oRHEIOpHZcsJ3cwQPnvGgpYgN-7QL1wVK1p9i5TkF1M=V1WGGx25-FFHMK9tBiwtnoorucA7awj3GnNj3nsW6PI=CnopnYT7-3STKkgqG6A71mur-xpEHLK3cOh7h3Q9gWg=>
> Mute This Topic: https://lists.fd.io/mt/29984675/675152 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fd.io_mt_29984675_675152=DwMFaQ=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2=oRHEIOpHZcsJ3cwQPnvGgpYgN-7QL1wVK1p9i5TkF1M=V1WGGx25-FFHMK9tBiwtnoorucA7awj3GnNj3nsW6PI=NnvJrsKkfQYb8gK0nC_3G6aSwWxodEl4Mqef6uYoWuo=>
> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fd.io_g_vpp-2Ddev_unsub=DwMFaQ=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2=oRHEIOpHZcsJ3cwQPnvGgpYgN-7QL1wVK1p9i5TkF1M=V1WGGx25-FFHMK9tBiwtnoorucA7awj3GnNj3nsW6PI=2d5h4w64qtw57R_jXBt9UyMIjPaaYIQ63nM1p-Ba4wE=>
>   [fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12314): https://lists.fd.io/g/vpp-dev/message/12314
Mute This Topic: https://lists.fd.io/mt/29984675/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] iperf3 with vcl

2019-02-21 Thread Florin Coras
Hi Ram,

What os and what vpp version? We’re constantly running iperf3 in our CI in 
ubuntu 18.04.

Thanks,
Florin

> On Feb 20, 2019, at 6:07 PM, Ramaraj Pandian  wrote:
> 
> I am trying to run iperf server and client to measure performance between two 
> vpp instances as per “https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 
>  “ but I get the following 
> error(unable to set TCP_CONGESTION) on client side? Any insights into this? I 
> would appreciate your help.
>  
> vppcom_session_close:1079: vcl<62624:0>: session handle 1 [0x3] 
> removed
> iperf3: error - unable to set TCP_CONGESTION: Supplied congestion control 
> algorithm not supported on this host
> ldp_destructor:3375: LDP<62624>: LDP destructor: done!
> vl_client_disconnect:330: queue drain: 605
> vl_client_disconnect:330: queue drain: 619
>  
> Thanks
> Ram
>  
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12306): https://lists.fd.io/g/vpp-dev/message/12306 
> 
> Mute This Topic: https://lists.fd.io/mt/29984675/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] vpp-verify-master-centos failures

2019-02-01 Thread Florin Coras
Just a heads up to everyone. 

I’ve tried rebuilding vpp with cleared ccache (rm -rf build-root/.ccache/*) and 
on my ubuntu 18.04 with gcc 7.3.0 it turned out to be really slow. For some 
reason gcc seems to be stalling towards the end of the build. To see if this is 
gcc specific, I installed gcc8 and it turns out it’s much faster.

I don’t know if this is just an isolated issue for my box or a genuine bug. So, 
before starting to think about a gcc upgrade, could others confirm the issue?

Florin

> On Feb 1, 2019, at 6:46 AM, Ed Kern (ejk)  wrote:
> 
> 
> 
>> On Feb 1, 2019, at 7:06 AM, Andrew  Yourtchenko  wrote:
>> 
>> Can we retrieve a high watermark of the container memory usage during
>> a job run ?
>> 
> 
> So my answer to that is ‘I have no idea’
> 
> The memory allocation from my ‘automated’ point of view happens during make 
> pkg-deb or
> make test  (for example).  Looking at the memory before or after those 
> commands are
> run is pointless because they are low/nil.
> 
> The way i have seen allocations in the past is just by running builds by hand 
> so I have
> a separate terminal attached to monitor.
> 
> This ‘works’ with the exception of the oom killer that will sometimes shoot 
> things down if
> there is huge memory spike in the ‘middle’.  Ive seen this with some java 
> bits.
> 
> 
>> Then we could take that, multiply by 2, for sanity verify that it is
>> not larger than the previous 3x times 3 (i.e. 9x)and verify if it hits
>> the previously configured limit of 3x, and if it does, then install a
>> new 3x number, and if needs to, decrease the number of concurrently
>> running jobs accordingly, and send the notification about that.
>> 
>> This would a manual process to rest in a simple and relatively safe
>> fashion, what do you think ?
>> 
> 
> would still be a manual process to change the number but sure..   
> 
> If someone had a slick way to see max memory usage during any
> section of a ‘make ’  that would be awesome.
> 
> Ed
> 
> 
> 
>> --a
>> 
>> On 2/1/19, Ed Kern via Lists.Fd.Io  wrote:
>>> Request with numbers has been made.  Not a ci-man change so it requires
>>> vanessa, but she
>>> is typically super fast turning around these changes, so hopefully in a
>>> couple hours.
>>> 
>>> Apologies for the trouble.   We have seen a 4-6x increase (depending on OS)
>>> in the last 5 months
>>> and so it finally started pinching my memory reservations of 'everything it
>>> needs x3’.
>>> 
>>> Ed
>>> 
>>> 
>>> 
>>> 
>>>> On Jan 31, 2019, at 6:26 PM, Florin Coras  wrote:
>>>> 
>>>> It seems centos verify jobs are failing with errors of the type:
>>>> 
>>>> 00:27:16
>>>> FAILED: vnet/CMakeFiles/vnet.dir/span/node.c.o
>>>> 
>>>> 00:27:16 ccache /opt/rh/devtoolset-7/root/bin/cc -DWITH_LIBSSL=1
>>>> -Dvnet_EXPORTS -I/w/workspace/vpp-verify-master-centos7/src -I. -Iinclude
>>>> -Wno-address-of-packed-member -march=corei7 -mtune=corei7-avx -g -O2
>>>> -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror -fPIC   -Wall -MD -MT
>>>> vnet/CMakeFiles/vnet.dir/span/node.c.o -MF
>>>> vnet/CMakeFiles/vnet.dir/span/node.c.o.d -o
>>>> vnet/CMakeFiles/vnet.dir/span/node.c.o   -c
>>>> /w/workspace/vpp-verify-master-centos7/src/vnet/span/node.c
>>>> 
>>>> I suspect this may be a memory issue. Could someone with ci superpowers
>>>> try increasing it for the centos containers?
>>>> 
>>>> Thanks,
>>>> Florin
>>> 
>>> 
> 

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

View/Reply Online (#12131): https://lists.fd.io/g/vpp-dev/message/12131
Mute This Topic: https://lists.fd.io/mt/29613366/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] L2 with LISP

2019-01-31 Thread Florin Coras
We support L2 only as an overlay. The underlay is always IPv4 or IPv6. Check 
the examples here [1, 2] to see how you can configure it.

Florin 

[1] 
https://git.fd.io/one/tree/tests/data_plane/configs/vpp_lite_config/basic/l2o4 
<https://git.fd.io/one/tree/tests/data_plane/configs/vpp_lite_config/basic/l2o4>
[2] 
https://git.fd.io/one/tree/tests/data_plane/configs/vpp_lite_config/basic/l2o4_with_adj
 
<https://git.fd.io/one/tree/tests/data_plane/configs/vpp_lite_config/basic/l2o4_with_adj>


> On Jan 31, 2019, at 12:46 PM, yosvany  wrote:
> 
> Tomorrow i will send  you more details.
>  
> Can send me one example how implement LISP with L2 and bd, (What comand need 
> use and what make MAC ADDRES TO RLOC???)
>  
>  
>  
>  
> De: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] En nombre de Florin 
> Coras
> Enviado el: viernes, 1 de febrero de 2019 3:13
> Para: Yosvany mailto:yosvan...@nauta.cu>>
> CC: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Asunto: Re: [vpp-dev] VPP send map-register with R=0 on LISP
>  
> I think I understand the problem now, but I don’t understand your last point. 
> Does vpp send a map-reply and if yes, does it look okay?
>  
> If it does not, we’re back to my first question about syslog. 
>  
> Florin
> 
> 
>> On Jan 31, 2019, at 11:49 AM, Yosvany > <mailto:yosvan...@nauta.cu>> wrote:
>>  
>>  
>> Again, do you see any error in /var/log/syslog for vni 0? 
>>  
>> · I nedd to check.
>>  
>> And do you mean that the map-reply from vpp to cisco router is not accepted 
>> in the cisco router?
>>  
>> · This is the problem. 
>> 
>>
>>  
>>  
>> Cisco MR/MS – (Can see information about 
>> registration of VPP and Cisco Xtr)
>>  
>>  
>>  
>> VPP xTr-- Cisco xTR
>>  
>> Can see the RLOC CiscoXTR I cant see any Information
>> Show one eid-table remote
>>  
>> Conclusion: Cisco XTR receive a bad Map-Reply from VPP.
>>  
>> · Another problem is that VPP is making a Loop sending
>> map-request to  MR/MS. In this map-request can se a map-reply.
>>  
>>  
>> De: Florin Coras [mailto:fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>] 
>> Enviado el: jueves, 31 de enero de 2019 6:13
>> Para: yosvany mailto:yosvan...@nauta.cu>>
>> Asunto: Re: [vpp-dev] VPP send map-register with R=0 on LISP
>>  
>> Again, do you see any error in /var/log/syslog for vni 0? 
>>  
>> And do you mean that the map-reply from vpp to cisco router is not accepted 
>> in the cisco router?
>>  
>> Florin
>>  
>> 
>>> On Jan 30, 2019, at 1:41 PM, yosvany >> <mailto:yosvan...@nauta.cu>> wrote:
>>>  
>>> We need use wireshark to compare replys and request.
>>>  
>>>  
>>> What about /var/log/syslog? Do you have any lisp specific errors there?
>>>  
>>> Seems that you have v6 traffic going for vni 10. Did you statically 
>>> configure the mapping for fd00:74::/48? If not, then map-replies with vni 
>>> non 0 seem to be working.
>>>  
>>> · fd00:74::/48 is local eid statically configured. Map replies only 
>>> work from cisco router as xtr when vni is different that 0
>>>  
>>> What map-reply isn’t correctly parsed? Is it for the v4 eid in vni 10 or 
>>> for the v4 in vni 20?
>>>  
>>> · Only work vni 10 this is cisco router, xtr vpp isn’t correctly 
>>> parsed  [10] fd00:0:76::/48remote  
>>> 192.168.76.60 1440   
>>>  
>>>  
>>> Florin
>> 
>>  
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#12109): https://lists.fd.io/g/vpp-dev/message/12109 
>> <https://lists.fd.io/g/vpp-dev/message/12109>
>> Mute This Topic: https://lists.fd.io/mt/29613581/675152 
>> <https://lists.fd.io/mt/29613581/675152>
>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP send map-register with R=0 on LISP

2019-01-31 Thread Florin Coras
I think I understand the problem now, but I don’t understand your last point. 
Does vpp send a map-reply and if yes, does it look okay?

If it does not, we’re back to my first question about syslog. 

Florin

> On Jan 31, 2019, at 11:49 AM, Yosvany  wrote:
> 
>  
> Again, do you see any error in /var/log/syslog for vni 0? 
>  
> · I nedd to check.
>  
> And do you mean that the map-reply from vpp to cisco router is not accepted 
> in the cisco router?
>  
> · This is the problem. 
> 
>
>  
>  
> Cisco MR/MS – (Can see information about 
> registration of VPP and Cisco Xtr)
>  
>  
>  
> VPP xTr-- Cisco xTR
>  
> Can see the RLOC CiscoXTR I cant see any Information
> Show one eid-table remote
>  
> Conclusion: Cisco XTR receive a bad Map-Reply from VPP.
>  
> · Another problem is that VPP is making a Loop sendingmap-request 
> to  MR/MS. In this map-request can se a map-reply.
>  
>  
> De: Florin Coras [mailto:fcoras.li...@gmail.com 
> <mailto:fcoras.li...@gmail.com>] 
> Enviado el: jueves, 31 de enero de 2019 6:13
> Para: yosvany mailto:yosvan...@nauta.cu>>
> Asunto: Re: [vpp-dev] VPP send map-register with R=0 on LISP
>  
> Again, do you see any error in /var/log/syslog for vni 0? 
>  
> And do you mean that the map-reply from vpp to cisco router is not accepted 
> in the cisco router?
>  
> Florin
>  
> 
> On Jan 30, 2019, at 1:41 PM, yosvany  <mailto:yosvan...@nauta.cu>> wrote:
>  
> We need use wireshark to compare replys and request.
>  
>  
> What about /var/log/syslog? Do you have any lisp specific errors there?
>  
> Seems that you have v6 traffic going for vni 10. Did you statically configure 
> the mapping for fd00:74::/48? If not, then map-replies with vni non 0 seem to 
> be working.
>  
> · fd00:74::/48 is local eid statically configured. Map replies only 
> work from cisco router as xtr when vni is different that 0
>  
> What map-reply isn’t correctly parsed? Is it for the v4 eid in vni 10 or for 
> the v4 in vni 20?
>  
> · Only work vni 10 this is cisco router, xtr vpp isn’t correctly 
> parsed  [10] fd00:0:76::/48remote  192.168.76.60  
>1440   
>  
>  
> Florin
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12109): https://lists.fd.io/g/vpp-dev/message/12109 
> <https://lists.fd.io/g/vpp-dev/message/12109>
> Mute This Topic: https://lists.fd.io/mt/29613581/675152 
> <https://lists.fd.io/mt/29613581/675152>
> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
> <mailto:fcoras.li...@gmail.com>]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


[vpp-dev] vpp-verify-master-centos failures

2019-01-31 Thread Florin Coras
It seems centos verify jobs are failing with errors of the type: 

00:27:16 
FAILED: vnet/CMakeFiles/vnet.dir/span/node.c.o 

00:27:16 ccache /opt/rh/devtoolset-7/root/bin/cc -DWITH_LIBSSL=1 -Dvnet_EXPORTS 
-I/w/workspace/vpp-verify-master-centos7/src -I. -Iinclude 
-Wno-address-of-packed-member -march=corei7 -mtune=corei7-avx -g -O2 
-DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror -fPIC   -Wall -MD -MT 
vnet/CMakeFiles/vnet.dir/span/node.c.o -MF 
vnet/CMakeFiles/vnet.dir/span/node.c.o.d -o 
vnet/CMakeFiles/vnet.dir/span/node.c.o   -c 
/w/workspace/vpp-verify-master-centos7/src/vnet/span/node.c

I suspect this may be a memory issue. Could someone with ci superpowers try 
increasing it for the centos containers?

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

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


Re: [vpp-dev] VPP 19.01 release is out!

2019-01-31 Thread Florin Coras
Awesome! Thanks, Andrew!

Florin

> On Jan 31, 2019, at 1:05 PM, Andrew Yourtchenko  wrote:
> 
> Hi all,
> 
> I am happy to announce that 19.01 release is now available.
> 
> Release artificats can be found on both Nexus and Packagecloud.
> 
> Thanks to all the contributors and committers, and also special
> thanks from me who helped to make this adventurous ride a little smoother.
> 
> I would like to say special big thanks to Paul Vinciguerra for his
> wonderful help tracking the moving target of some python packages we
> consume in make test, their release dates happened to coincide with
> ours just close enough to cause very interesting race conditions.
> 
> --a
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12102): https://lists.fd.io/g/vpp-dev/message/12102
> Mute This Topic: https://lists.fd.io/mt/29610895/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12104): https://lists.fd.io/g/vpp-dev/message/12104
Mute This Topic: https://lists.fd.io/mt/29610895/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] Packet copy in plugins/nsim

2019-01-31 Thread Florin Coras
Hi Raj,

Partly. Check “show buffers”

Florin

> On Jan 31, 2019, at 1:04 AM, Raj  wrote:
> 
> Hi Florin,
> 
> On Wed, Jan 30, 2019 at 10:01 PM Florin Coras  wrote:
> 
>> Because if it can work with all of its buffers cached, without flushing them 
>> to main memory, it can access and therefore ‘process’ them faster.
> 
> Understood. Is there any means to see how many buffers are in use
> currently, and if they are cached?
> 
>> It's two copies vs more buffer memory, not bigger buffers. Flushing and 
>> reading buffers to/from main memory are pretty much copy operations.
>> Nsim typically needs a lot of buffer memory, therefore instead of trashing 
>> the cache and potentially impacting other vpp components, it directly stores 
>> everything in memory.
> 
> That's clear.
> 
> Thanks!
> 
> Raj
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12088): https://lists.fd.io/g/vpp-dev/message/12088
> Mute This Topic: https://lists.fd.io/mt/29581029/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP send map-register with R=0 on LISP

2019-01-30 Thread Florin Coras
What about /var/log/syslog? Do you have any lisp specific errors there?

Seems that you have v6 traffic going for vni 10. Did you statically configure 
the mapping for fd00:74::/48? If not, then map-replies with vni non 0 seem to 
be working.

What map-reply isn’t correctly parsed? Is it for the v4 eid in vni 10 or for 
the v4 in vni 20?

Florin


> On Jan 30, 2019, at 11:56 AM, yosvany  wrote:
> 
> Look the show error
>  
> vpp# show error
>CountNode  Reason
>334   dpdk-input   no error
>166  lisp-cp-input drop
>165  lisp-cp-input map-notifies received
> 14   lisp-cp-lookup-ip6   drop
>165 lisp-cp-output map-registers sent
>  2 lisp-cp-output map-requests sent
> 32arp-input   ARP replies sent
> 70arp-input   IP4 source address not 
> local to subnet
>  2arp-input   ARP request IP4 source 
> address learned
>   2880ip4-input   Multicast RPF check failed
>  1ip4-glean   ARP requests sent
>109 ip6-icmp-input valid packets
>  1 ip6-icmp-input neighbor advertisements 
> received
> 57 ip6-icmp-input router advertisements sent
>109 ip6-icmp-input router advertisements 
> received
>  
>  
> vpp# show int addr
> GigabitEthernet0/13/0 (up):
>   L3 192.168.74.59/29
> GigabitEthernet0/14/0 (up):
>   L3 10.74.0.1/30 ip4 table-id 10 fib-idx 1
>   L3 fd00:74:100::2/64 ip6 table-id 10 fib-idx 1
> GigabitEthernet0/15/0 (up):
>   L3 172.8.0.1/30 ip4 table-id 20 fib-idx 2
> lisp_gpe0 (up):
> lisp_gpe10 (up):
> lisp_gpe10.0 (up):
> lisp_gpe20 (up):
> local0 (dn):
> vpp#
> vpp#
> vpp#
> vpp# show one locator-set
> Locator-set LocatorPriority Weight
> xx   1   1 100
>192.168.76.60   1 100
> vpp#
> vpp#
> vpp# show one eid-table local
> EIDtypelocators   
>ttl authoritative
> [10] fd00:74::/48  local(xx)   GigabitEthernet0/13/0  
>0   1
> [10] 10.74.0.0/16  local(xx)   GigabitEthernet0/13/0  
>0   1
> [20] 172.8.0.0/16  local(xx)   GigabitEthernet0/13/0  
>0   1
> vpp#
> vpp#
> vpp# show one eid-table map l33
> vpp# show one eid-table map l3
> VNI   VRF
> 1010
>  0 0
> 2020
> vpp#
> vpp#
> vpp# show one eid-table remote
> EIDtypelocators   
>ttl authoritative
> [10] fd00:0:76::/48remote  192.168.76.60  
>14401This is other cisco router sonly working as 
> XTR
> vpp#
> vpp#
> vpp#
> vpp#
> vpp# show one st
> statistics  status
> vpp# show one statistics details
> [src-EID, dst-EID] [loc-rloc, rmt-rloc] count bytes
> [fd00:74::/48, fd00:0:76::/48] [192.168.74.59, 192.168.76.60]   18499  887952
> vpp#
> vpp#
>  
> De: Florin Coras [mailto:fcoras.li...@gmail.com] 
> Enviado el: jueves, 31 de enero de 2019 1:12
> Para: Yosvany 
> CC: vpp-dev@lists.fd.io
> Asunto: Re: [vpp-dev] VPP send map-register with R=0 on LISP
>  
> As per previous email, please check for any errors reported by lisp-cp in cli 
> and syslog. 
>  
> Florin 
> 
> 
>> On Jan 30, 2019, at 9:50 AM, Yosvany > <mailto:yosvan...@nauta.cu>> wrote:
>>  
>> Yes was solved, but we have map-reply problem, it is drop by lisp-cp when 
>> vni is differents that 0.
>> 
>> 
>> 
>> El 29 de enero de 2019 8:37:45 PM GMT-05:00, Florin Coras 
>> mailto:fcoras.li...@gmail.com>> escribió:
>>> Does this [1] solve the issue?
>>> 
>>> Florin
>>> 
>>> [1] https://gerrit.fd.io/r/#/c/17151/ <https://gerrit.fd.io/r/#/c/17151/>On 
>>> Jan 29, 2019, at 4:34 PM, Yosvany >> <mailto:yosvan...@nauta.cu>> wrote:
>>>> 
>>>> VPP with LISP send the reachable bit to 0. When use one iid to vni 
>>>> different that 0.
>>>> 
>>>> How can change the reachable bit to 1 on map-register.
>>

Re: [vpp-dev] VPP send map-register with R=0 on LISP

2019-01-30 Thread Florin Coras
As per previous email, please check for any errors reported by lisp-cp in cli 
and syslog. 

Florin 

> On Jan 30, 2019, at 9:50 AM, Yosvany  wrote:
> 
> Yes was solved, but we have map-reply problem, it is drop by lisp-cp when vni 
> is differents that 0.
> 
> 
> 
> El 29 de enero de 2019 8:37:45 PM GMT-05:00, Florin Coras 
> mailto:fcoras.li...@gmail.com>> escribió:
> Does this [1] solve the issue?
> 
> Florin
> 
> [1] https://gerrit.fd.io/r/#/c/17151/ <https://gerrit.fd.io/r/#/c/17151/>
> 
> On Jan 29, 2019, at 4:34 PM, Yosvany  wrote:
> 
> VPP with LISP send the reachable bit to 0. When use one iid to vni different 
> that 0.
> 
> How can change the reachable bit to 1 on map-register.
> 
> I am testing with cisco router as MS/MR.
> -- 
> Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
> brevedad. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12052): https://lists.fd.io/g/vpp-dev/message/12052 
> <https://lists.fd.io/g/vpp-dev/message/12052>
> Mute This Topic: https://lists.fd.io/mt/29589087/675152 
> <https://lists.fd.io/mt/29589087/675152>
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com]
> 
> 
> -- 
> Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
> brevedad.

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

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


Re: [vpp-dev] VPP delete map-reply from cisco router

2019-01-30 Thread Florin Coras
Hi Paul,

We don’t have lisp control message tracing. But it may very well be that the 
new pcap tracer is enough. 

Florin

> On Jan 30, 2019, at 11:49 AM, Paul Vinciguerra  
> wrote:
> 
> Hi Florin,
> 
> Is lisp control message tracing needed, or is it better to use the new 
> wireshark extensions?
> 
> On Wed, Jan 30, 2019 at 1:23 PM Florin Coras  <mailto:fcoras.li...@gmail.com>> wrote:
> Yosvany, 
> 
> The trace you provided shows that the packet was processed okay and then 
> dropped. Do you see any lisp errors if you do “show error” or in syslog?
> 
> It may turn out to be that we don’t have a parser for some record in the 
> map-reply. Note that testing has been done exclusively with ODL 
> LispFlowMapping MS/MR, so we only support the record types it generates. 
> 
> Florin
> 
> > On Jan 30, 2019, at 9:35 AM, Yosvany  > <mailto:yosvan...@nauta.cu>> wrote:
> > 
> > VPP are delete LISP map reply from cisco router as LISP MR/MS when VPP are 
> > making Map-Request to good EID.
> > 
> > The problem is when vni map to iid is differents that 0.
> > 
> > When response map-reply is native forward, VPP work fine.
> > 
> > When response is good VPP dont show the result on one eid-table remote.
> > 
> > Look show trace in txt file as lip-cp delete udp packet.
> > 
> > Best Regard.
> > 
> > 
> > -- 
> > Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
> > brevedad. -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#12070): https://lists.fd.io/g/vpp-dev/message/12070 
> > <https://lists.fd.io/g/vpp-dev/message/12070>
> > Mute This Topic: https://lists.fd.io/mt/29596854/675152 
> > <https://lists.fd.io/mt/29596854/675152>
> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev%2bow...@lists.fd.io>
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> > <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
> > <mailto:fcoras.li...@gmail.com>]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12072): https://lists.fd.io/g/vpp-dev/message/12072 
> <https://lists.fd.io/g/vpp-dev/message/12072>
> Mute This Topic: https://lists.fd.io/mt/29596854/1594641 
> <https://lists.fd.io/mt/29596854/1594641>
> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev%2bow...@lists.fd.io>
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://lists.fd.io/g/vpp-dev/unsub>  [pvi...@vinciconsulting.com 
> <mailto:pvi...@vinciconsulting.com>]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP delete map-reply from cisco router

2019-01-30 Thread Florin Coras
Yosvany, 

The trace you provided shows that the packet was processed okay and then 
dropped. Do you see any lisp errors if you do “show error” or in syslog?

It may turn out to be that we don’t have a parser for some record in the 
map-reply. Note that testing has been done exclusively with ODL LispFlowMapping 
MS/MR, so we only support the record types it generates. 

Florin

> On Jan 30, 2019, at 9:35 AM, Yosvany  wrote:
> 
> VPP are delete LISP map reply from cisco router as LISP MR/MS when VPP are 
> making Map-Request to good EID.
> 
> The problem is when vni map to iid is differents that 0.
> 
> When response map-reply is native forward, VPP work fine.
> 
> When response is good VPP dont show the result on one eid-table remote.
> 
> Look show trace in txt file as lip-cp delete udp packet.
> 
> Best Regard.
> 
> 
> -- 
> Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
> brevedad. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12070): https://lists.fd.io/g/vpp-dev/message/12070
> Mute This Topic: https://lists.fd.io/mt/29596854/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12072): https://lists.fd.io/g/vpp-dev/message/12072
Mute This Topic: https://lists.fd.io/mt/29596854/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] Packet copy in plugins/nsim

2019-01-30 Thread Florin Coras
Hi Raj, 

> On Jan 30, 2019, at 6:49 AM, Raj  wrote:
> 
> Hello Florin,
> 
> Thanks a lot for your reply.
> 
> On Tue, Jan 29, 2019 at 9:15 PM Florin Coras  wrote:
>> 
>> VPP typically works best if configured with a relatively small number of 
>> buffers.
> 
> I am trying to understand why this would be the case.

Because if it can work with all of its buffers cached, without flushing them to 
main memory, it can access and therefore ‘process’ them faster. 

> 
>> On the other hand, nsim can induce a large amount of delay, so the buffers 
>> cannot be used to temporarily store the data.
> 
> If my understanding is correct, the comparison is between two packet
> copy per packet and performance degradation due to bigger buffers. How
> would they compare?

It's two copies vs more buffer memory, not bigger buffers. Flushing and reading 
buffers to/from main memory are pretty much copy operations. Nsim typically 
needs a lot of buffer memory, therefore instead of trashing the cache and 
potentially impacting other vpp components, it directly stores everything in 
memory.   

Florin

> 
> Thanks and Regards,
> 
> Raj
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12065): https://lists.fd.io/g/vpp-dev/message/12065
> Mute This Topic: https://lists.fd.io/mt/29581029/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP send map-register with R=0 on LISP

2019-01-29 Thread Florin Coras
Does this [1] solve the issue?

Florin

[1] https://gerrit.fd.io/r/#/c/17151/

> On Jan 29, 2019, at 4:34 PM, Yosvany  wrote:
> 
> VPP with LISP send the reachable bit to 0. When use one iid to vni different 
> that 0.
> 
> How can change the reachable bit to 1 on map-register.
> 
> I am testing with cisco router as MS/MR.
> -- 
> Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
> brevedad. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12052): https://lists.fd.io/g/vpp-dev/message/12052
> Mute This Topic: https://lists.fd.io/mt/29589087/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12054): https://lists.fd.io/g/vpp-dev/message/12054
Mute This Topic: https://lists.fd.io/mt/29589087/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] RFC: buffer manager rework

2019-01-25 Thread Florin Coras
Awesome! Looking forward to using it in the host stack ;-)

Florin

> On Jan 25, 2019, at 9:08 AM, Damjan Marion via Lists.Fd.Io 
>  wrote:
> 
> 
> I am very close to the finish line with buffer management rework patch, and 
> would like to 
> ask people to take a look before it is merged.
> 
> https://gerrit.fd.io/r/16638
> 
> It significantly improves performance of buffer alloc free and introduces 
> numa awareness.
> On my skylake platinum 8180 system, with native AVF driver observed 
> performance improvement is:
> 
> - single core, 2 threads, ipv4 base forwarding test, CPU running at 2.5GHz 
> (TB off):
> 
> old code - dpdk buffer manager: 20.4 Mpps
> old code - old native buffer manager: 19.4 Mpps
> new code: 24.9 Mpps
> 
> With DPDK drivers performance stays same as DPDK is maintaining own internal 
> buffer cache. 
> So major perf gain should be observed in native code like: vhost-user, memif, 
> AVF, host stack.
> 
> user facing changes:
> to change number of buffers:
>  old startup.conf:
>dpdk { num-mbufs  } 
>  new startup.conf:
>buffers { buffers-per-numa }
> 
> Internal changes:
> - free lists are deprecated
> - buffer metadata is always initialised.
> - first 64-bytes of metadata are initialised on free, so buffer alloc is very 
> fast
> - DPDK mempools are not used anymore, we register custom mempool ops, and 
> dpdk is taking buffers from VPP
> - to support such operation plugin can request external header space - in 
> case of DPDK it stores rte_mbuf + rte_mempool_objhdr
> 
> I'm still running some tests so possible minor changes are possible, but 
> nothing major expected.
> 
> -- 
> Damjan
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12016): https://lists.fd.io/g/vpp-dev/message/12016
> Mute This Topic: https://lists.fd.io/mt/29539221/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12018): https://lists.fd.io/g/vpp-dev/message/12018
Mute This Topic: https://lists.fd.io/mt/29539221/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] wireshark vpp dispatch trace dissector merged

2019-01-17 Thread Florin Coras
Awesome!

Florin

> On Jan 17, 2019, at 5:11 AM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> I’m pleased to announce that our dispatch trace wireshark dissector has been 
> merged. At some point in the indefinite future, everyone’s favorite distro 
> will include a copy of wireshark which knows how to dissect vpp dispatch 
> trace pcap files.
>  
> I’ll update the docs accordingly.
>  
> Dave
>  
> From: bugzilla-dae...@wireshark.org  
> mailto:bugzilla-dae...@wireshark.org>> 
> Sent: Thursday, January 17, 2019 6:32 AM
> To: wiresh...@barachs.net 
> Subject: [Bug 15411] [dissector] Add dissector for vector packet processing 
> dispatch traces
>  
> Comment # 2  on 
> bug 15411  from 
> Gerrit Code Review 
> Change 31466 merged by Anders Broman:
> VPP: add vpp graph dispatch trace dissector
>  
> https://code.wireshark.org/review/31466 
> 
> You are receiving this mail because:
> You reported the bug.
> You are the assignee for the bug.
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11939): https://lists.fd.io/g/vpp-dev/message/11939 
> 
> Mute This Topic: https://lists.fd.io/mt/29172119/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] vpp + spdk - spdk crash on getting work item

2019-01-11 Thread Florin Coras
Ramaraj, 

You’ll have to check with the SPDK guys, but I think they’re still based on 
ubuntu 18.07. 

If you’re trying to run SPDK with vcl, so not using the patch that I previously 
pointed you to, probably it won’t work. VCL needs explicit configuration of 
workers and, from the crash lower, I suspect that is not done properly. 

Florin

> On Jan 11, 2019, at 10:15 AM, Ramaraj Pandian  wrote:
> 
> I am getting following panic while running SPDK target with VPP, Am I missing 
> any configuration related settings? Any insights would be helpful.
>  
> Thanks
> Ram
>  
>  
> (gdb) bt
> #0  0x7f0182108207 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7f01821098f8 in __GI_abort () at abort.c:90
> #2  0x7f01815f7068 in os_panic () at 
> /vpp-master/src/vppinfra/unix-misc.c:176
> #3  0x7f018155821f in debugger () at /vpp-master/src/vppinfra/error.c:84
> #4  0x7f018155865a in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x7f01826fa2a8 "%s:%d (%s) assertion `%s' fails")
> at /vpp-master/src/vppinfra/error.c:143
> #5  0x7f01826c8da0 in vcl_worker_get (wrk_index=4294967295) at 
> /vpp-master/src/vcl/vcl_private.h:541
> #6  0x7f01826c8fa8 in vcl_worker_get_current () at 
> /vpp-master/src/vcl/vcl_private.h:555
> #7  0x7f01826d2b4f in vppcom_epoll_create () at 
> /vpp-master/src/vcl/vppcom.c:2482
> #8  0x0046ad7e in spdk_vpp_sock_group_impl_create () at vpp.c:507
> #9  0x004a6f09 in spdk_sock_group_create () at sock.c:189
> #10 0x004816ed in spdk_nvmf_tcp_poll_group_create 
> (transport=0x968b90) at tcp.c:1273
> #11 0x0047ddd3 in spdk_nvmf_transport_poll_group_create 
> (transport=0x968b90) at transport.c:167
> #12 0x0047c80f in spdk_nvmf_poll_group_add_transport 
> (group=0x7f0179d0, transport=0x968b90) at nvmf.c:836
> #13 0x0047ae83 in spdk_nvmf_tgt_create_poll_group 
> (io_device=0x97b330, ctx_buf=0x7f0179d0) at nvmf.c:120
> #14 0x0048d642 in spdk_get_io_channel (io_device=0x97b330) at 
> thread.c:865
> #15 0x0047c153 in spdk_nvmf_poll_group_create (tgt=0x97b330) at 
> nvmf.c:630
> #16 0x004714c3 in nvmf_tgt_create_poll_group (ctx=0x0) at 
> nvmf_tgt.c:294
> #17 0x0048c99d in spdk_on_thread (ctx=0x969890) at thread.c:610
> #18 0x0048c06d in _spdk_msg_queue_run_batch (thread=0x7f0178c0, 
> max_msgs=8) at thread.c:318
> #19 0x0048c210 in spdk_thread_poll (thread=0x7f0178c0, 
> max_msgs=0) at thread.c:359
> #20 0x00487ea6 in _spdk_reactor_run (arg=0x967400) at reactor.c:320
> #21 0x00407442 in eal_thread_loop.cold.1 ()
> #22 0x7f01824a6dd5 in start_thread (arg=0x7f0180d18700) at 
> pthread_create.c:307
> #23 0x7f01821cfead in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11900): https://lists.fd.io/g/vpp-dev/message/11900 
> 
> Mute This Topic: https://lists.fd.io/mt/29018354/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11902): https://lists.fd.io/g/vpp-dev/message/11902
Mute This Topic: https://lists.fd.io/mt/29018354/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] Sequence Number Checking in TCP Protocol

2019-01-02 Thread Florin Coras
Hi Jim, 

Here’s the patch [1].

Regards, 
Florin

[1] https://gerrit.fd.io/r/#/c/16675/

> On Dec 29, 2018, at 10:59 PM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> 
> 
>> On Dec 29, 2018, at 8:26 PM, Jim Thompson  wrote:
>> 
>> 
>> 
>>> On Dec 29, 2018, at 6:42 PM, Florin Coras  wrote:
>>> 
>>> Hi Jim, 
>>> 
>>> That has to do with the initial sequence number generation.
>> 
>> Understood.  Thus the title of "Defending against Sequence Number Attacks"
>> 
>>> We don’t exactly implement that algorithm but we do generate the initial 
>>> sequence number randomly based on time. 
>> 
>> Understood.  Currently we do:
>> 
>>  tc->iss = random_u32 (_now); 
> 
> Yup.
> 
>> 
>> in tcp_init_snd_vars(), but I’m not sure that’s not a RFC violation. Quoting:
>> 
>>  "If random numbers are used as the sole source of the secret, they MUST be 
>> chosen in accordance with the recommendations given in RFC4086.”
>> 
>> If it isn’t, fine.   If it is, then the question becomes:  "Would adding a 4 
>> usec timer be harmful to the host stack?"
>> 
>> From inspection it looks like all the other data to call the RFC-recommended
>> 
>>  tc->iss = M + F (localip, localport, remoteip, remoteport, secretkey)
>> 
>> is present.  (Where M is the current value of that 4 usec timer, F is MD5, 
>> and secretkey is some value we pick up or generate during VPP startup.)
> 
> We could just use vlib time for that. I’ll add it to my list, in case nobody 
> beats me to it.
> 
> Florin
> 
>> 
>> Jim
>> 
>>> 
>>> Florin
>>> 
>>>> On Dec 29, 2018, at 12:42 PM, Jim Thompson  wrote:
>>>> 
>>>> 
>>>> Florian,
>>>> 
>>>> Maybe he wants RFC 6528. 
>>>> 
>>>> Jim 
>>>> 
>>>>> On Dec 29, 2018, at 10:59 AM, Florin Coras  wrote:
>>>>> 
>>>>> Hi Brayan, 
>>>>> 
>>>>> I’m not entirely sure I understand your question. Obviously, we have 
>>>>> sequence validation in tcp as per rfc 793. For details, see 
>>>>> tcp_segment_validate in tcp_input.c. As part of that function, we also 
>>>>> check for paws as per rfc 1323/7323. 
>>>>> 
>>>>> Hope this helps,
>>>>> Florin
>>>>> 
>>>>>> On Dec 29, 2018, at 5:29 AM, brayan ortega  
>>>>>> wrote:
>>>>>> 
>>>>>> Dear VPP Folks,
>>>>>> 
>>>>>> I would like to know about sequence number checking functionality. Is 
>>>>>> this functionality implemented already? 
>>>>>> 1- If yes: Guide me about that
>>>>>> 2- If no : Is there any plan for sequence number checking 
>>>>>> implementation? it seems it is essential to prevent sequence number 
>>>>>> prediction attacks. 
>>>>>> 
>>>>>> Best Regards,
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>>> Links: You receive all messages sent to this group.
>>>>>> 
>>>>>> View/Reply Online (#11795): https://lists.fd.io/g/vpp-dev/message/11795
>>>>>> Mute This Topic: https://lists.fd.io/mt/28880091/675152
>>>>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
>>>>>> [fcoras.li...@gmail.com]
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>> 
>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>> Links: You receive all messages sent to this group.
>>>>> 
>>>>> View/Reply Online (#11796): https://lists.fd.io/g/vpp-dev/message/11796
>>>>> Mute This Topic: https://lists.fd.io/mt/28880091/675164
>>>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [j...@netgate.com]
>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> 
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11800): https://lists.fd.io/g/vpp-dev/message/11800 
> <https://lists.fd.io/g/vpp-dev/message/11800>
> Mute This Topic: https://lists.fd.io/mt/28880091/675152 
> <https://lists.fd.io/mt/28880091/675152>
> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
> <mailto:fcoras.li...@gmail.com>]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP 19.01 + SPDK

2019-01-02 Thread Florin Coras
Hi Ram, 

Tomasz cc'ed, amongst others, have been working on integrating SPDK with VPP's 
host stack. Maybe the patch here [1] can provide some answers.

Florin

[1] https://review.gerrithub.io/c/spdk/spdk/+/417056   

> On Jan 2, 2019, at 2:05 PM, Ramaraj Pandian  wrote:
> 
> Hello,
>  
> I am new to VPP and trying to integrate VPP with SPDK. I see old VPP version 
> generates .a files as well along with .so files which were useful to SPDK 
> with. But latest version, it generates only .so files, I tried to change 
> /src/cmake/library.cmake to build static library as well but build fails:
>  
> : && ccache /opt/rh/devtoolset-7/root/bin/cc -march=corei7 -mtune=corei7-avx 
> -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 -fstack-protector-all -fPIC -Werror  
> -Wl,--export-dynamic -rdynamic vat/CMakeFiles/vpp_api_test.dir/api_format.c.o 
> vat/CMakeFiles/vpp_api_test.dir/main.c.o 
> vat/CMakeFiles/vpp_api_test.dir/plugin.c.o 
> vat/CMakeFiles/vpp_api_test.dir/json_format.c.o 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o  -o bin/vpp_api_test  
> -Wl,-rpath,
>  vlibmemory/libvlibmemoryclient.a svm/libsvm.a vat/libvatplugin.a 
> vppinfra/libvppinfra.a -lrt -lm -ldl -lcrypto -lpthread -pthread && :
> vat/libvatplugin.a(plugin_api.c.o): In function `unformat_ip4_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:39: multiple 
> definition of `unformat_ip4_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:197:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `unformat_ethernet_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:59: multiple 
> definition of `unformat_ethernet_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:217:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function 
> `unformat_ethernet_type_host_byte_order':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:82: multiple 
> definition of `unformat_ethernet_type_host_byte_order'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:240:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `unformat_ip6_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:100: multiple 
> definition of `unformat_ip6_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:258:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `format_ip4_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:191: multiple 
> definition of `format_ip4_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:640:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `format_ip6_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:198: multiple 
> definition of `format_ip6_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:647:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `format_ip46_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:249: multiple 
> definition of `format_ip46_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:698:
>  first defined here
> vat/libvatplugin.a(plugin_api.c.o): In function `format_ethernet_address':
> /home/nr.pandian/projects/vpp-main-19.01/src/vat/plugin_api.c:274: multiple 
> definition of `format_ethernet_address'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:723:
>  first defined here
> vppinfra/libvppinfra.a(std-formats.c.o): In function `format_hex_bytes':
> /home/nr.pandian/projects/vpp-main-19.01/src/vppinfra/std-formats.c:85: 
> multiple definition of `format_hex_bytes'
> vat/CMakeFiles/vpp_api_test.dir/api_format.c.o:/home/nr.pandian/projects/vpp-main-19.01/src/vat/api_format.c:4920:
>  first defined here
> collect2: error: ld returned 1 exit status
> [548/558] Building C object vcl/CMakeFiles/vppcom.dir/vcl_bapi.c.o
> ninja: build stopped: subcommand failed.
> make[1]: *** [vpp-build] Error 1
> make[1]: Leaving directory 
> `/home/nr.pandian/projects/vpp-main-19.01/build-root'
> make: *** [build] Error 2
>  
>  
> Can someone shed light on this?
>  
> Thanks
> Ram
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11818): https://lists.fd.io/g/vpp-dev/message/11818 
> 
> Mute This Topic: https://lists.fd.io/mt/28918688/675152 
> 
> Group Owner: 

Re: [vpp-dev] Sequence Number Checking in TCP Protocol

2018-12-29 Thread Florin Coras


> On Dec 29, 2018, at 8:26 PM, Jim Thompson  wrote:
> 
> 
> 
>> On Dec 29, 2018, at 6:42 PM, Florin Coras  wrote:
>> 
>> Hi Jim, 
>> 
>> That has to do with the initial sequence number generation.
> 
> Understood.  Thus the title of "Defending against Sequence Number Attacks"
> 
>> We don’t exactly implement that algorithm but we do generate the initial 
>> sequence number randomly based on time. 
> 
> Understood.  Currently we do:
> 
>   tc->iss = random_u32 (_now); 

Yup.

> 
> in tcp_init_snd_vars(), but I’m not sure that’s not a RFC violation. Quoting:
> 
>   "If random numbers are used as the sole source of the secret, they MUST be 
> chosen in accordance with the recommendations given in RFC4086.”
> 
> If it isn’t, fine.   If it is, then the question becomes:  "Would adding a 4 
> usec timer be harmful to the host stack?"
> 
> From inspection it looks like all the other data to call the RFC-recommended
> 
>   tc->iss = M + F (localip, localport, remoteip, remoteport, secretkey)
> 
> is present.  (Where M is the current value of that 4 usec timer, F is MD5, 
> and secretkey is some value we pick up or generate during VPP startup.)

We could just use vlib time for that. I’ll add it to my list, in case nobody 
beats me to it.

Florin

> 
> Jim
> 
>> 
>> Florin
>> 
>>> On Dec 29, 2018, at 12:42 PM, Jim Thompson  wrote:
>>> 
>>> 
>>> Florian,
>>> 
>>> Maybe he wants RFC 6528. 
>>> 
>>> Jim 
>>> 
>>>> On Dec 29, 2018, at 10:59 AM, Florin Coras  wrote:
>>>> 
>>>> Hi Brayan, 
>>>> 
>>>> I’m not entirely sure I understand your question. Obviously, we have 
>>>> sequence validation in tcp as per rfc 793. For details, see 
>>>> tcp_segment_validate in tcp_input.c. As part of that function, we also 
>>>> check for paws as per rfc 1323/7323. 
>>>> 
>>>> Hope this helps,
>>>> Florin
>>>> 
>>>>> On Dec 29, 2018, at 5:29 AM, brayan ortega  
>>>>> wrote:
>>>>> 
>>>>> Dear VPP Folks,
>>>>> 
>>>>> I would like to know about sequence number checking functionality. Is 
>>>>> this functionality implemented already? 
>>>>> 1- If yes: Guide me about that
>>>>> 2- If no : Is there any plan for sequence number checking implementation? 
>>>>> it seems it is essential to prevent sequence number prediction attacks. 
>>>>> 
>>>>> Best Regards,
>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>> Links: You receive all messages sent to this group.
>>>>> 
>>>>> View/Reply Online (#11795): https://lists.fd.io/g/vpp-dev/message/11795
>>>>> Mute This Topic: https://lists.fd.io/mt/28880091/675152
>>>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
>>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>> 
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>> Links: You receive all messages sent to this group.
>>>> 
>>>> View/Reply Online (#11796): https://lists.fd.io/g/vpp-dev/message/11796
>>>> Mute This Topic: https://lists.fd.io/mt/28880091/675164
>>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [j...@netgate.com]
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
> 

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

View/Reply Online (#11800): https://lists.fd.io/g/vpp-dev/message/11800
Mute This Topic: https://lists.fd.io/mt/28880091/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] Sequence Number Checking in TCP Protocol

2018-12-29 Thread Florin Coras
Hi Jim, 

That has to do with the initial sequence number generation. We don’t exactly 
implement that algorithm but we do generate the initial sequence number 
randomly based on time. 

Florin

> On Dec 29, 2018, at 12:42 PM, Jim Thompson  wrote:
> 
> 
> Florian,
> 
> Maybe he wants RFC 6528. 
> 
> Jim 
> 
>> On Dec 29, 2018, at 10:59 AM, Florin Coras  wrote:
>> 
>> Hi Brayan, 
>> 
>> I’m not entirely sure I understand your question. Obviously, we have 
>> sequence validation in tcp as per rfc 793. For details, see 
>> tcp_segment_validate in tcp_input.c. As part of that function, we also check 
>> for paws as per rfc 1323/7323. 
>> 
>> Hope this helps,
>> Florin
>> 
>>> On Dec 29, 2018, at 5:29 AM, brayan ortega  
>>> wrote:
>>> 
>>> Dear VPP Folks,
>>> 
>>> I would like to know about sequence number checking functionality. Is this 
>>> functionality implemented already? 
>>> 1- If yes: Guide me about that
>>> 2- If no : Is there any plan for sequence number checking implementation? 
>>> it seems it is essential to prevent sequence number prediction attacks. 
>>> 
>>> Best Regards,
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#11795): https://lists.fd.io/g/vpp-dev/message/11795
>>> Mute This Topic: https://lists.fd.io/mt/28880091/675152
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#11796): https://lists.fd.io/g/vpp-dev/message/11796
>> Mute This Topic: https://lists.fd.io/mt/28880091/675164
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [j...@netgate.com]
>> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11798): https://lists.fd.io/g/vpp-dev/message/11798
Mute This Topic: https://lists.fd.io/mt/28880091/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] Sequence Number Checking in TCP Protocol

2018-12-29 Thread Florin Coras
Hi Brayan, 

I’m not entirely sure I understand your question. Obviously, we have sequence 
validation in tcp as per rfc 793. For details, see tcp_segment_validate in 
tcp_input.c. As part of that function, we also check for paws as per rfc 
1323/7323. 

Hope this helps,
Florin

> On Dec 29, 2018, at 5:29 AM, brayan ortega  
> wrote:
> 
> Dear VPP Folks,
> 
> I would like to know about sequence number checking functionality. Is this 
> functionality implemented already? 
> 1- If yes: Guide me about that
> 2- If no : Is there any plan for sequence number checking implementation? it 
> seems it is essential to prevent sequence number prediction attacks. 
> 
> Best Regards,
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11795): https://lists.fd.io/g/vpp-dev/message/11795
> Mute This Topic: https://lists.fd.io/mt/28880091/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP Failing (all?) Verify Jobs

2018-12-27 Thread Florin Coras
Paul came up with a better fix [1]. Rebasing of the patches should solve the 
verify problems now. 

Florin

[1] https://gerrit.fd.io/r/#/c/16631/

> On Dec 27, 2018, at 9:54 AM, Florin Coras via Lists.Fd.Io 
>  wrote:
> 
> Hi Jon,
> 
> Yeah, it’s an osleap problem. As far as I can tell, the issue is not with 
> make install-dep step but with this one [1]. Not entirely sure about the 
> solution but maybe a “-f” would force the installation of the newer package?
> 
> Marco, Vanessa, Ed, any other suggestions?
> 
> Florin
> 
> [1] 
> https://gerrit.fd.io/r/gitweb?p=ci-management.git;a=blob;f=jjb/scripts/setup_vpp_dpdk_dev_env.sh;h=b40d7af68038154f3cbb4b1280f5852fae1e5fe3;hb=refs/heads/master
>  
> <https://gerrit.fd.io/r/gitweb?p=ci-management.git;a=blob;f=jjb/scripts/setup_vpp_dpdk_dev_env.sh;h=b40d7af68038154f3cbb4b1280f5852fae1e5fe3;hb=refs/heads/master>
> 
>> On Dec 27, 2018, at 8:48 AM, Jon Loeliger > <mailto:j...@netgate.com>> wrote:
>> 
>> Folks,
>> 
>> It looks like VPP is failing (all?) verify jobs as it is unable to build
>> some variant.  Looks like a failed 'make install-dep' is wedging on
>> a Boost lib install.  (Build 9/9.)
>> 
>> Any insight here?
>> 
>> Thanks,
>> jdl
>> 
>> 
>> Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts 
>> with namespace:otherproviders(libboost_headers-devel) provided by 
>> libboost_headers-devel-1.69.0-lp150.1.1.noarch
>> Problem: libboost_thread1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts 
>> with namespace:otherproviders(libboost_thread-devel) provided by 
>> libboost_thread-devel-1.69.0-lp150.1.1.noarch
>> 
>> Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts 
>> with namespace:otherproviders(libboost_headers-devel) provided by 
>> libboost_headers-devel-1.69.0-lp150.1.1.noarch
>>  Solution 1: Following actions will be done:
>>   deinstallation of libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64
>>   deinstallation of libboost_chrono1_68_0-devel-1.68.0-lp150.243.1.x86_64
>>   deinstallation of libboost_date_time1_68_0-devel-1.68.0-lp150.243.1.x86_64
>>  Solution 2: do not install libboost_headers-devel-1.69.0-lp150.1.1.noarch
>> 
>> Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] 
>> (c): c
>> make: *** [Makefile:316: install-dep] Error 4
>> Build step 'Execute shell' marked build as failure
>> $ ssh-agent -k
>> unset SSH_AUTH_SOCK;
>> unset SSH_AGENT_PID;
>> echo Agent pid 63 killed;
>> [ssh-agent] Stopped.
>> Skipped archiving because build is not successful
>> [PostBuildScript] - Executing post build scripts.
>> [vpp-verify-master-osleap15] $ /bin/bash /tmp/jenkins2611708312337033426.sh
>> Build logs: > href="https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269
>>  
>> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269>">https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269
>>  
>> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269>
>> uname -a:
>>  Linux f4f9bd3f69b6 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27 10:45:01 
>> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#11777): https://lists.fd.io/g/vpp-dev/message/11777 
>> <https://lists.fd.io/g/vpp-dev/message/11777>
>> Mute This Topic: https://lists.fd.io/mt/28866309/675152 
>> <https://lists.fd.io/mt/28866309/675152>
>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io>
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>> <https://lists.fd.io/g/vpp-dev/unsub>  [fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11778): https://lists.fd.io/g/vpp-dev/message/11778
> Mute This Topic: https://lists.fd.io/mt/28866309/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP Failing (all?) Verify Jobs

2018-12-27 Thread Florin Coras
Hi Jon,

Yeah, it’s an osleap problem. As far as I can tell, the issue is not with make 
install-dep step but with this one [1]. Not entirely sure about the solution 
but maybe a “-f” would force the installation of the newer package?

Marco, Vanessa, Ed, any other suggestions?

Florin

[1] 
https://gerrit.fd.io/r/gitweb?p=ci-management.git;a=blob;f=jjb/scripts/setup_vpp_dpdk_dev_env.sh;h=b40d7af68038154f3cbb4b1280f5852fae1e5fe3;hb=refs/heads/master

> On Dec 27, 2018, at 8:48 AM, Jon Loeliger  wrote:
> 
> Folks,
> 
> It looks like VPP is failing (all?) verify jobs as it is unable to build
> some variant.  Looks like a failed 'make install-dep' is wedging on
> a Boost lib install.  (Build 9/9.)
> 
> Any insight here?
> 
> Thanks,
> jdl
> 
> 
> Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts 
> with namespace:otherproviders(libboost_headers-devel) provided by 
> libboost_headers-devel-1.69.0-lp150.1.1.noarch
> Problem: libboost_thread1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts with 
> namespace:otherproviders(libboost_thread-devel) provided by 
> libboost_thread-devel-1.69.0-lp150.1.1.noarch
> 
> Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64 conflicts 
> with namespace:otherproviders(libboost_headers-devel) provided by 
> libboost_headers-devel-1.69.0-lp150.1.1.noarch
>  Solution 1: Following actions will be done:
>   deinstallation of libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64
>   deinstallation of libboost_chrono1_68_0-devel-1.68.0-lp150.243.1.x86_64
>   deinstallation of libboost_date_time1_68_0-devel-1.68.0-lp150.243.1.x86_64
>  Solution 2: do not install libboost_headers-devel-1.69.0-lp150.1.1.noarch
> 
> Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] 
> (c): c
> make: *** [Makefile:316: install-dep] Error 4
> Build step 'Execute shell' marked build as failure
> $ ssh-agent -k
> unset SSH_AUTH_SOCK;
> unset SSH_AGENT_PID;
> echo Agent pid 63 killed;
> [ssh-agent] Stopped.
> Skipped archiving because build is not successful
> [PostBuildScript] - Executing post build scripts.
> [vpp-verify-master-osleap15] $ /bin/bash /tmp/jenkins2611708312337033426.sh
> Build logs:  href="https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269
>  
> ">https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269
>  
> 
> uname -a:
>  Linux f4f9bd3f69b6 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27 10:45:01 UTC 
> 2018 x86_64 x86_64 x86_64 GNU/Linux 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11777): https://lists.fd.io/g/vpp-dev/message/11777
> Mute This Topic: https://lists.fd.io/mt/28866309/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11778): https://lists.fd.io/g/vpp-dev/message/11778
Mute This Topic: https://lists.fd.io/mt/28866309/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] regarding cross compiling

2018-12-19 Thread Florin Coras
Let me reiterate what Dave said: the committer community saw real value in 
moving to cmake. Those extra build minutes are subtracted from the lives of 
those who build vpp on a daily basis. 

Florin

> On Dec 19, 2018, at 8:46 AM, Andrew Pinski  wrote:
> 
> On Wed, Dec 19, 2018 at 11:29 AM Dave Barach (dbarach)
> mailto:dbar...@cisco.com>> wrote:
>> 
>> Please give the instructions at 
>> https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling
>>  
>> 
>>  a try and let us know what happens.
> 
> Wow.  So much harder to do than what autoconf provides.  I think going
> to cmake is a mistake and that it needs to be reverted.  Again the
> only reason why VPP moved was for faster compiling by what a few
> minutes but provide a messy interface to use instead.  I guess VPP
> does not care about easy of compiling but would rather have faster
> compiling.
> 
> Thanks,
> Andrew Pinski
> 
>> 
>> Suffice it to say that the vpp committer community saw sufficient value in 
>> switching to cmake to do so.
>> 
>> D.
>> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  On Behalf Of Andrew Pinski
>> Sent: Wednesday, December 19, 2018 10:40 AM
>> To: dmar...@me.com
>> Cc: Saxena, Nitin ; vpp-dev@lists.fd.io
>> Subject: Re: [vpp-dev] regarding cross compiling
>> 
>> On Wed, Dec 19, 2018 at 8:54 AM Damjan Marion via Lists.Fd.Io 
>>  wrote:
>>> 
>>> i
>>> 
>>> On 19 Dec 2018, at 14:00, Saxena, Nitin  wrote:
>>> 
>>> Hi Damjan,
>>> 
> Somebody needs to spend a bit of time to teach CMake how to properly 
> cross-compile
>>> 
>>> Correct me if I am wrong but I think cross-compilation support was there 
>>> before CMake transition.
>>> 
>>> I guess so, never used it...
>> 
>> I am still disappointed moving away from autotools.  CMake has too much junk 
>> science of getting it right; autotools just work for all of these special 
>> cases.
>> Yes it is a bit slower to build with autotools but it makes cross compiling 
>> and debugging what is going wrong with the build easier.
>> 
>>> 
>>> Also I am not finding capability to link VPP with externally compiled
>>> dpdk? Am I correct or missing anything
>>> 
>>> You can just specify -DCMAKE_INSTALL_PREFIX:PATH=. to the tree where 
>>> dpdk tree is.
>>> That is what we do today with /opt/vpp/external/$(uname -m)/
>> 
>> Also it makes help messages from configure easier to find the needed options 
>> including but not limited to the above.  Having reading cmake files in the 
>> past and autoconfig files, the autoconf is easier to understand and 
>> understand how it works.  Also autoconf is standard, while cmake is very 
>> much unstandardized when it comes to finding headers, etc.  You need to pull 
>> in a library, here have a weird cmake file which might or might not work.
>> 
>> Thanks,
>> Andrew Pinski
>> 
>>> 
>>> --
>>> Damjan
>>> 
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#11694):
>>> https://lists.fd.io/g/vpp-dev/message/11694
>>> Mute This Topic: https://lists.fd.io/mt/28800506/912176
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [pins...@gmail.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11701): https://lists.fd.io/g/vpp-dev/message/11701 
> 
> Mute This Topic: https://lists.fd.io/mt/28800506/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP/Envoy integration status

2018-12-06 Thread Florin Coras
Hi Dai, 

No. The release plan is just a statement of intent. The actual release notes 
are here [1].

I know there are ongoing efforts in this area but I’m not sure about their 
current status. 

Florin

[1] https://git.fd.io/vpp/tree/RELEASE.md

> On Dec 6, 2018, at 2:34 PM, via Lists.Fd.Io 
>  wrote:
> 
> Hello,
>  
> Was VPP/Envoy integration delivered in VPP 18.07 as mentioned in the release 
> plan (https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.07 
> )? I 
> cannot seem to find the code nor any setup instructions in VPP 18.07 (or 
> 18.10) branch.
>  
> Thanks,
> Dai
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11516): https://lists.fd.io/g/vpp-dev/message/11516 
> 
> Mute This Topic: https://lists.fd.io/mt/28631119/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


[vpp-dev] sshd with vpp's host stack and LD_PRELOAD

2018-12-04 Thread Florin Coras
Folks, 

I know there has been quite some interest in running sshd with the host stack, 
so here’s a quick update on where that stands. 

Dave and I have been working on supporting applications that fork children with 
vcl and, to actually test the code, we’ve decided to run sshd on top of it. 
Because we already had the ldp library, we opted to make our lives easier and 
use it instead of modifying sshd. That doesn’t mean ldp has been optimized or 
that it will work with any other app. It does however mean that, to some 
extent, vcl can now work with apps that don’t do anything more “fancy” than 
what sshd does. 

If you want to test this, see [1], but “here be dragons”! I’ve done most of the 
testing with a locally compiled sshd, with and without gdb, on an ubuntu 
18.04.1. It also works with the package provided sshd, but I’ve noticed that it 
behaves slightly differently. Therefore, I wouldn’t be totally surprised if 
didn’t work on other systems. 

Florin

[1] https://wiki.fd.io/view/VPP/HostStack/LDP/sshd-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11490): https://lists.fd.io/g/vpp-dev/message/11490
Mute This Topic: https://lists.fd.io/mt/28607272/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] Verify issues (GRE)

2018-12-03 Thread Florin Coras
Hi Juraj, 

Could you try exporting VCL_DEBUG=1 (or higher) before running the tests?

Florin

> On Dec 3, 2018, at 3:41 AM, Juraj Linkeš  wrote:
> 
> Hi Florin,
>  
> So the tests should work fine in parallel, thanks for the clarification.
>  
> I tried running the tests again and I could reproduce it with keyboard 
> interrupt or when the test produced a core (and was then killed by the parent 
> run_tests process), but the logs don't say anything - just that the server 
> and client were started and that's where the logs stop. I guess the child vcl 
> worker process is not handled in this case, though I wonder why 
> run_in_venv_with_cleanup.sh doesn't clean it up.
>  
> Juraj
>  
> From: Florin Coras [mailto:fcoras.li...@gmail.com] 
> Sent: Thursday, November 29, 2018 5:04 PM
> To: Juraj Linkeš 
> Cc: Ole Troan ; vpp-dev 
> Subject: Re: [vpp-dev] Verify issues (GRE)
>  
> Hi Juraj, 
>  
> Those tests exercise the stack in vpp, so they don’t use up linux stack 
> ports. Moreover, both cut-through and through-the-stack tests use 
> self.shm_prefix when connecting to vpp’s binary api. So, as long as that 
> variable is properly updated, VCL and implicitly LDP will attach and use 
> ports on the right vpp instance. 
>  
> As for sock_test_client/server not being properly killed, did you find 
> something in the logs that would indicate why it happened? 
>  
> Florin
> 
> 
> On Nov 29, 2018, at 3:18 AM, Juraj Linkeš  <mailto:juraj.lin...@pantheon.tech>> wrote:
>  
> Hi Ole,
>  
> I've noticed a few thing about the VCL testcases:
> -The VCL testcasess are all using the same ports, which makes them 
> unsuitable for parallel test runs
> -Another thing about these testcases is that when they're don't 
> finish properly the sock_test_server and client stay running as zombie 
> processes (and thus use up ports). It's easily reproducible locally by 
> interrupting the tests, but I'm not sure whether this could actually arise in 
> CI
> -Which means that if one testcase finishes improperly (e.g. is killed 
> because of a timeout) all of the other VCL testcases will likely also fail
>  
> Hope this helps if there's anyone looking into those tests,
> Juraj
>  
> From: Ole Troan [mailto:otr...@employees.org <mailto:otr...@employees.org>] 
> Sent: Wednesday, November 28, 2018 7:56 PM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] Verify issues (GRE)
>  
> Guys,
> 
> The verify job have been unstable over the last few days.
> We see some instability in the Jenkins build system, in the test harness 
> itself, and in the tests.
> On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.
> 
> It looks like Jenkins is functioning correctly now.
> Ed and I are also testing a revert of all the changes made to the test 
> framework itself over the last couple of days. A bit harsh, but we think this 
> might be the quickest way back to some level of stability.
> 
> Then we need to fix the tests that are in themselves unstable.
> 
> Any volunteers to see if they can figure out why GRE fails?
> 
> Cheers,
> Ole
> 
> 
> GRE Test Case 
> ==
> GRE IPv4 tunnel TestsOK
> GRE IPv6 tunnel TestsOK
> GRE tunnel L2 Tests  OK
> 19:37:47,505 Unexpected packets captured:
> Packet #0:
>   0201FF0202FE70A06AD308004500 p.j...E.
> 0010  002A00013F11219FAC100101AC10 .*?.!...
> 0020  010204D204D2001672A9343336392033 r.4369 3
> 0030  2033202D31202D31  3 -1 -1
> 
> ###[ Ethernet ]### 
>   dst   = 02:01:00:00:ff:02
>   src   = 02:fe:70:a0:6a:d3
>   type  = IPv4
> ###[ IP ]### 
>  version   = 4
>  ihl   = 5
>  tos   = 0x0
>  len   = 42
>  id= 1
>  flags = 
>  frag  = 0
>  ttl   = 63
>  proto = udp
>  chksum= 0x219f
>  src   = 172.16.1.1
>  dst   = 172.16.1.2
>  \options   \
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> Ten more packets
> 
> 
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> ** Ten more pa

Re: [vpp-dev] Verify issues (GRE)

2018-11-29 Thread Florin Coras
Hi Juraj, 

Those tests exercise the stack in vpp, so they don’t use up linux stack ports. 
Moreover, both cut-through and through-the-stack tests use self.shm_prefix when 
connecting to vpp’s binary api. So, as long as that variable is properly 
updated, VCL and implicitly LDP will attach and use ports on the right vpp 
instance. 

As for sock_test_client/server not being properly killed, did you find 
something in the logs that would indicate why it happened? 

Florin

> On Nov 29, 2018, at 3:18 AM, Juraj Linkeš  wrote:
> 
> Hi Ole,
>  
> I've noticed a few thing about the VCL testcases:
> -The VCL testcasess are all using the same ports, which makes them 
> unsuitable for parallel test runs
> -Another thing about these testcases is that when they're don't 
> finish properly the sock_test_server and client stay running as zombie 
> processes (and thus use up ports). It's easily reproducible locally by 
> interrupting the tests, but I'm not sure whether this could actually arise in 
> CI
> -Which means that if one testcase finishes improperly (e.g. is killed 
> because of a timeout) all of the other VCL testcases will likely also fail
>  
> Hope this helps if there's anyone looking into those tests,
> Juraj
>  
> From: Ole Troan [mailto:otr...@employees.org ] 
> Sent: Wednesday, November 28, 2018 7:56 PM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] Verify issues (GRE)
>  
> Guys,
> 
> The verify job have been unstable over the last few days.
> We see some instability in the Jenkins build system, in the test harness 
> itself, and in the tests.
> On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.
> 
> It looks like Jenkins is functioning correctly now.
> Ed and I are also testing a revert of all the changes made to the test 
> framework itself over the last couple of days. A bit harsh, but we think this 
> might be the quickest way back to some level of stability.
> 
> Then we need to fix the tests that are in themselves unstable.
> 
> Any volunteers to see if they can figure out why GRE fails?
> 
> Cheers,
> Ole
> 
> 
> GRE Test Case 
> ==
> GRE IPv4 tunnel TestsOK
> GRE IPv6 tunnel TestsOK
> GRE tunnel L2 Tests  OK
> 19:37:47,505 Unexpected packets captured:
> Packet #0:
>   0201FF0202FE70A06AD308004500 p.j...E.
> 0010  002A00013F11219FAC100101AC10 .*?.!...
> 0020  010204D204D2001672A9343336392033 r.4369 3
> 0030  2033202D31202D31  3 -1 -1
> 
> ###[ Ethernet ]### 
>   dst   = 02:01:00:00:ff:02
>   src   = 02:fe:70:a0:6a:d3
>   type  = IPv4
> ###[ IP ]### 
>  version   = 4
>  ihl   = 5
>  tos   = 0x0
>  len   = 42
>  id= 1
>  flags = 
>  frag  = 0
>  ttl   = 63
>  proto = udp
>  chksum= 0x219f
>  src   = 172.16.1.1
>  dst   = 172.16.1.2
>  \options   \
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> Ten more packets
> 
> 
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> ** Ten more packets
> 
> Print limit reached, 10 out of 257 packets printed
> 19:37:47,770 REG: Couldn't remove configuration for object(s):
> 19:37:47,770 
> GRE tunnel VRF Tests 
> ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestGRE-hthaHC ]
> 
> ==
> ERROR: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 61, in tearDown
> super(TestGRE, self).tearDown()
>   File "/vpp/16257/test/framework.py", line 546, in tearDown
> self.registry.remove_vpp_config(self.logger)
>   File "/vpp/16257/test/vpp_object.py", line 86, in remove_vpp_config
> (", ".join(str(x) for x in failed)))
> Exception: Couldn't remove configuration for object(s): 1:2.2.2.2/32
> 
> ==
> FAIL: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 787, in test_gre_vrf
> remark="GRE decap packets in wrong VRF")
>   File "/vpp/16257/test/vpp_pg_interface.py", line 264, in 
> assert_nothing_captured
> (self.name, remark))
> 

Re: [vpp-dev] vppcom: why __vcl_worker_index is thread local? #vpp

2018-11-28 Thread Florin Coras
I am working on enabling forking with LDP but keep in mind that we mainly 
support it for testing purposes. That is, it can’t work with statically linked 
applications and we don’t plan on supporting all possible 
socket/setsockopts/getsockopts/fcntl options. 

Florin

> On Nov 28, 2018, at 3:15 AM, manuel.alo...@cavium.com wrote:
> 
> Ok, thank you for the clarification. So, as far as I understand, host-stack 
> preloading is not intended to work with forkable(because of the ldp 
> destructor) and/or threadable(because of mentioned index) applications.
> 
> 
> BR,
> Manuel -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11443): https://lists.fd.io/g/vpp-dev/message/11443
> Mute This Topic: https://lists.fd.io/mt/28286895/675152
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] About in-band telnet/ssh support of VPP

2018-11-27 Thread Florin Coras
We’re working on adding support via LDP/VCL but anything not finished is pretty 
much unusable. We’re trying to finish it as soon as possible but no idea if 
it’ll make it into 19.01

Florin

> On Nov 27, 2018, at 6:08 AM, tianye  wrote:
> 
> That is a in-band solution.
> No fun :-)
> 
> 
> 在 2018年11月27日,20:38,Dave Barach (dbarach)  > 写道:
> 
>> If you want/need a solution 90 seconds ago, take a look 
>> here:https://wiki.fd.io/view/VPP/VPP_Home_Gateway 
>> 
>>  
>> Add a user (“admin”, maybe?) whose login shell is vppctl, and you’re done.
>>  
>> Please don’t create a gigantic security hole.
>>  
>> D.
>>  
>> From: tianye@sina mailto:tiany...@sina.com>> 
>> Sent: Tuesday, November 27, 2018 12:19 AM
>> To: 'Hu, Xuekun' mailto:xuekun...@intel.com>>; Dave 
>> Barach (dbarach) mailto:dbar...@cisco.com>>; 
>> vpp-dev@lists.fd.io 
>> Subject: RE: [vpp-dev] About in-band telnet/ssh support of VPP
>>  
>> Partially completed work will also be welcome if you agree to share.
>> Or you can just push your temporary work to sandbox gerrit so that anyone 
>> could get some idea about how to porting.
>> You never understand how we need it J
>>  
>> From: Hu, Xuekun [mailto:xuekun...@intel.com ] 
>> Sent: Tuesday, November 27, 2018 12:58 PM
>> To: dbar...@cisco.com ; tianye@sina; 
>> vpp-dev@lists.fd.io 
>> Subject: RE: [vpp-dev] About in-band telnet/ssh support of VPP
>>  
>> Dave, can you estimate when the sshd work to be done? We really like this 
>> feature.
>> Thanks. 
>>  
>>  <>From: vpp-dev@lists.fd.io  
>> mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach 
>> via Lists.Fd.Io
>> Sent: Monday, November 26, 2018 8:42 PM
>> To: tianye@sina mailto:tiany...@sina.com>>; 
>> vpp-dev@lists.fd.io 
>> Cc: vpp-dev@lists.fd.io 
>> Subject: Re: [vpp-dev] About in-band telnet/ssh support of VPP
>>  
>> Please do not use the vpp host stack to listen to port 23 (telnet) on a 
>> network-facing interface. You could do that, but please don’t do that.
>>  
>> All you would need to add is a well-known default password, and you would 
>> have created a super-trivial attack surface for your product.
>>  
>> Florin and I are working to crank up sshd over the host stack. No guaranteed 
>> end-date, but it’s coming...
>>  
>> D.
>>  
>> From: vpp-dev@lists.fd.io  > > On Behalf Of tianye@sina
>> Sent: Sunday, November 25, 2018 9:10 PM
>> To: vpp-dev@lists.fd.io 
>> Subject: [vpp-dev] About in-band telnet/ssh support of VPP
>>  
>> Hello Everyone:
>>  
>> As we all knows, the latest VPP version 18.10 support telnet.
>> We can set the conf file like this to monitor the remote telnet request:
>> unix {
>>   cli-listen localhost 5002 or cli-listen 192.168. 5002
>>   …..
>>  
>> But actually the IP/Port pair we are listening is the “in-band” interface.
>> That means that interface belongs to the Linux host system(not the dedicate 
>> NIC pre-allocated for VPP)
>> Is there any solution for telnet/ssh toward the VPP in-band interface?
>> (Provide telnet/ssh support for in-band interface is very important when we 
>> managed to build a gateway/router device
>> over bare metal machine, since we cannot guarantee we can involve additional 
>> out-band interface with any topology and product cost limitation)
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11431): https://lists.fd.io/g/vpp-dev/message/11431 
> 
> Mute This Topic: https://lists.fd.io/mt/28320167/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] How to actively close the client connections in http server? #vnet

2018-11-23 Thread Florin Coras
Ow, so the issue is the reset. Could you try to call stream_session_disconnect 
instead of stream_session_cleanup in the handle?

Florin

> On Nov 22, 2018, at 6:51 AM, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> Florin Coras mailto:fcoras.li...@gmail.com>> schrieb 
> am Mi., 21. Nov. 2018 um 18:33 Uhr:
> 
>> On Nov 21, 2018, at 8:55 AM, Andreas Schultz > <mailto:andreas.schu...@travelping.com>> wrote:
>> 
>> Florin Coras mailto:fcoras.li...@gmail.com>> 
>> schrieb am Mi., 21. Nov. 2018 um 17:18 Uhr:
>> Hi Andreas, 
>> 
>> The trace lower suggests your tcp connection was freed but you still got 
>> data for it. tcp-input and the checks in established should prevent that 
>> from happening and the session layer should not receive any events after the 
>> transport notifies it that the session will cleaned up. 
> 
> I've found a way to reproduce the problem with a mostly unmodified vpp (see 
> attached patch for the changes).
> It turns that the crash is triggered when a tcp client is aborting 
> (resetting) the connection the hard way with a RST.
> 
> A normal connection close looks like this:
> 
> Client  Server (VPP)
> - [FIN,ACK] >
> < [FIN,ACK] - 
> --- [ACK] -->
> 
> The crash occurs when the connection is aborted like this:
> 
> Client  Server (VPP)
> - [RST,ACK] >
> 
> For the unmodified VPP the crash looks like this:
> 
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x776abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530
> 530 tc->flags &= ~TCP_CONN_DEQ_PENDING;
> (gdb) bt
> #0  0x776abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) 
> at /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530
> #1  0x776b1a6c in tcp46_established_inline (vm=0x7708f340 
> , node=0x7fffb927a3c0, frame=0x7fffb7619800, is_ip4=1) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2160
> #2  0x776b1b01 in tcp4_established (vm=0x7708f340 
> , node=0x7fffb927a3c0, from_frame=0x7fffb7619800) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2171
> #3  0x770043ec in dispatch_node (vm=0x7708f340 
> , node=0x7fffb927a3c0, type=VLIB_NODE_TYPE_INTERNAL, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb7619800, 
> last_time_stamp=67427903546971 )
> at /usr/src/components/vpp/src/vlib/main.c:1154
> #4  0x770049cc in dispatch_pending_node (vm=0x7708f340 
> , pending_frame_index=5, last_time_stamp=67427903546971 
> ) at /usr/src/components/vpp/src/vlib/main.c:1312
> #5  0x7700665f in vlib_main_or_worker_loop (vm=0x7708f340 
> , is_main=1) at /usr/src/components/vpp/src/vlib/main.c:1739
> #6  0x77006e38 in vlib_main_loop (vm=0x7708f340 
> ) at /usr/src/components/vpp/src/vlib/main.c:1813
> #7  0x77007be4 in vlib_main (vm=0x7708f340 , 
> input=0x7fffb6bfffb0) at /usr/src/components/vpp/src/vlib/main.c:2006
> #8  0x77062b90 in thread0 (arg=140737337946944) at 
> /usr/src/components/vpp/src/vlib/unix/main.c:606
> #9  0x76e73c98 in clib_calljmp () from 
> /usr/src/components/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
> #10 0x7fffd230 in ?? ()
> #11 0x7706305d in vlib_unix_main (argc=34, argv=0x55694230) at 
> /usr/src/components/vpp/src/vlib/unix/main.c:675
> #12 0xd404 in main (argc=34, argv=0x55694230) at 
> /usr/src/components/vpp/src/vpp/vnet/main.c:272
> 
> The reason I discovered this is that my VPP HTTP server is sending a 302 
> redirect with a Location header. In this case wget is doing something with 
> the connection that leads to the RST instead of a normal FIN.
> 
> Regards
> Andreas
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> <mailto:i...@travelping.com>
> GERMANY Web:http://www.travelping.com 
> <http://www.travelping.com/>
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> 

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

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


Re: [vpp-dev] vppcom: why __vcl_worker_index is thread local? #vpp

2018-11-23 Thread Florin Coras
It’s done on purpose in order to avoid constant locking. Applications should 
accept new session on the right thread. If you plan to distribute the load 
across multiple workers, then just have them all listen on the same ip:port 
tuple and vpp will load balance. 

Florin

> On Nov 22, 2018, at 6:54 AM, at.man...@gmail.com wrote:
> 
> Hello all,
> Having that index in the thread context is breaking run-time of 
> multi-threaded applications. Most of them accept connections in a main loop 
> and process data in a thread by passing the socket descriptor.
> I understand that there is no data protections across the interface 
> library..but, are there any other reasons, that I might be missing, for that?
> 
> Thanks in advance.
> Manuel -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11372): https://lists.fd.io/g/vpp-dev/message/11372
> Mute This Topic: https://lists.fd.io/mt/28286895/675152
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] How to actively close the client connections in http server? #vnet

2018-11-21 Thread Florin Coras


> On Nov 21, 2018, at 8:55 AM, Andreas Schultz  
> wrote:
> 
> Florin Coras mailto:fcoras.li...@gmail.com>> schrieb 
> am Mi., 21. Nov. 2018 um 17:18 Uhr:
> Hi Andreas, 
> 
> The trace lower suggests your tcp connection was freed but you still got data 
> for it. tcp-input and the checks in established should prevent that from 
> happening and the session layer should not receive any events after the 
> transport notifies it that the session will cleaned up. 
> 
> So, apart from calling vnet_disconnect_session () on an rx event, have you 
> done anything else to the code?
> 
> Not to the session code. I got a bit creative when creating the listening 
> session and feeding the packets to ip-input.
> 
> The actual code for the session process is here: 
> https://gerrit.fd.io/r/c/15801/6/src/plugins/upf/upf_http_redirect_server.c#222
>  
> <https://gerrit.fd.io/r/c/15801/6/src/plugins/upf/upf_http_redirect_server.c#222>
>  , I still need to address you comments there, but I don't think that this 
> has anything to do with the crash.
> 
> I'm going to test this a bit further with the http_server.

Ack. Do let me know what you find!

Cheers, 
Florin

> 
> Andreas
> 
> 
> Regards,
> Florin
> 
> 
>> On Nov 21, 2018, at 1:36 AM, Andreas Schultz > <mailto:andreas.schu...@travelping.com>> wrote:
>> 
>> Florin Coras mailto:fcoras.li...@gmail.com>> 
>> schrieb am Fr., 18. Mai 2018 um 08:12 Uhr:
>> That http server is just example code that executes the contents of a get 
>> request as a cli commands within a spawned vpp process. So, if you want to 
>> disconnect _after_ the the reply is sent, call vnet_disconnect_session () at 
>> the end of http_cli_process.
>> 
>> Came across this when searching for a similar problem.
>> 
>> I tried exactly what Florin suggested in the rx_callback handle. Doing so 
>> result in segmentation in multiple places.
>> 
>> The first in tcp_input:
>> 
>> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
>> 0x770d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) at 
>> /usr/src/vpp/src/vnet/tcp/tcp_input.c:530
>> 530tc->flags &= ~TCP_CONN_DEQ_PENDING;
>> (gdb) print tc
>> $1 = (tcp_connection_t *) 0x0
>> (gdb) bt
>> #0  0x770d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) 
>> at /usr/src/vpp/src/vnet/tcp/tcp_input.c:530
>> #1  0x770db8bb in tcp46_established_inline (vm=0x768f2340 
>> , node=0x7fffb6dc0600, frame=0x7fffb5e1afc0, is_ip4=1) at 
>> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2160
>> #2  0x770db951 in tcp4_established (vm=0x768f2340 
>> , node=0x7fffb6dc0600, from_frame=0x7fffb5e1afc0) at 
>> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2171
>> #3  0x76669ab2 in dispatch_node (vm=0x768f2340 
>> , node=0x7fffb6dc0600, type=VLIB_NODE_TYPE_INTERNAL, 
>> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5e1afc0, 
>> last_time_stamp=6761417783745271)
>> at /usr/src/vpp/src/vlib/main.c:1109
>> #4  0x7666a092 in dispatch_pending_node (vm=0x768f2340 
>> , pending_frame_index=10, 
>> last_time_stamp=6761417783745271) at /usr/src/vpp/src/vlib/main.c:1267
>> #5  0x7666bd23 in vlib_main_or_worker_loop (vm=0x768f2340 
>> , is_main=1) at /usr/src/vpp/src/vlib/main.c:1694
>> #6  0x7666c4fc in vlib_main_loop (vm=0x768f2340 
>> ) at /usr/src/vpp/src/vlib/main.c:1768
>> #7  0x7666d2a9 in vlib_main (vm=0x768f2340 , 
>> input=0x7fffb53fffb0) at /usr/src/vpp/src/vlib/main.c:1961
>> #8  0x766c7d2d in thread0 (arg=140737329963840) at 
>> /usr/src/vpp/src/vlib/unix/main.c:606
>> #9  0x75ee2e04 in clib_calljmp () from 
>> /usr/src/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
>> #10 0x7fffd0f0 in ?? ()
>> #11 0x766c81fa in vlib_unix_main (argc=44, argv=0x558939b0) at 
>> /usr/src/vpp/src/vlib/unix/main.c:675
>> #12 0xcce8 in main (argc=44, argv=0x558939b0) at 
>> /usr/src/vpp/src/vpp/vnet/main.c:272
>> 
>> After adding a check for tc == NULL, it crashes with
>> 
>> 0: /usr/src/vpp/src/vnet/session/session.h:394 (session_get_from_handle) 
>> assertion `! pool_is_free (smm->wrk[thread_index].sessions, _e)' fails
>> 
>> So it seems that is currently not possible to use vnet_disconnect_session () 
>> from a rx_callback directly.
>> 
>> Any hints on how to disconnect the tcp session from the rx callback?
>> 
>> Regards
>> Andreas
>> 
>> 
&

Re: [vpp-dev] How to actively close the client connections in http server? #vnet

2018-11-21 Thread Florin Coras
Hi Andreas, 

The trace lower suggests your tcp connection was freed but you still got data 
for it. tcp-input and the checks in established should prevent that from 
happening and the session layer should not receive any events after the 
transport notifies it that the session will cleaned up. 

So, apart from calling vnet_disconnect_session () on an rx event, have you done 
anything else to the code?

Regards,
Florin

> On Nov 21, 2018, at 1:36 AM, Andreas Schultz  
> wrote:
> 
> Florin Coras mailto:fcoras.li...@gmail.com>> schrieb 
> am Fr., 18. Mai 2018 um 08:12 Uhr:
> That http server is just example code that executes the contents of a get 
> request as a cli commands within a spawned vpp process. So, if you want to 
> disconnect _after_ the the reply is sent, call vnet_disconnect_session () at 
> the end of http_cli_process.
> 
> Came across this when searching for a similar problem.
> 
> I tried exactly what Florin suggested in the rx_callback handle. Doing so 
> result in segmentation in multiple places.
> 
> The first in tcp_input:
> 
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x770d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) at 
> /usr/src/vpp/src/vnet/tcp/tcp_input.c:530
> 530 tc->flags &= ~TCP_CONN_DEQ_PENDING;
> (gdb) print tc
> $1 = (tcp_connection_t *) 0x0
> (gdb) bt
> #0  0x770d5b25 in tcp_handle_postponed_dequeues (wrk=0x7fffb5ac5f00) 
> at /usr/src/vpp/src/vnet/tcp/tcp_input.c:530
> #1  0x770db8bb in tcp46_established_inline (vm=0x768f2340 
> , node=0x7fffb6dc0600, frame=0x7fffb5e1afc0, is_ip4=1) at 
> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2160
> #2  0x770db951 in tcp4_established (vm=0x768f2340 
> , node=0x7fffb6dc0600, from_frame=0x7fffb5e1afc0) at 
> /usr/src/vpp/src/vnet/tcp/tcp_input.c:2171
> #3  0x76669ab2 in dispatch_node (vm=0x768f2340 
> , node=0x7fffb6dc0600, type=VLIB_NODE_TYPE_INTERNAL, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5e1afc0, 
> last_time_stamp=6761417783745271)
> at /usr/src/vpp/src/vlib/main.c:1109
> #4  0x7666a092 in dispatch_pending_node (vm=0x768f2340 
> , pending_frame_index=10, last_time_stamp=6761417783745271) 
> at /usr/src/vpp/src/vlib/main.c:1267
> #5  0x7666bd23 in vlib_main_or_worker_loop (vm=0x768f2340 
> , is_main=1) at /usr/src/vpp/src/vlib/main.c:1694
> #6  0x7666c4fc in vlib_main_loop (vm=0x768f2340 
> ) at /usr/src/vpp/src/vlib/main.c:1768
> #7  0x7666d2a9 in vlib_main (vm=0x768f2340 , 
> input=0x7fffb53fffb0) at /usr/src/vpp/src/vlib/main.c:1961
> #8  0x766c7d2d in thread0 (arg=140737329963840) at 
> /usr/src/vpp/src/vlib/unix/main.c:606
> #9  0x75ee2e04 in clib_calljmp () from 
> /usr/src/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
> #10 0x7fffd0f0 in ?? ()
> #11 0x766c81fa in vlib_unix_main (argc=44, argv=0x558939b0) at 
> /usr/src/vpp/src/vlib/unix/main.c:675
> #12 0xcce8 in main (argc=44, argv=0x558939b0) at 
> /usr/src/vpp/src/vpp/vnet/main.c:272
> 
> After adding a check for tc == NULL, it crashes with
> 
> 0: /usr/src/vpp/src/vnet/session/session.h:394 (session_get_from_handle) 
> assertion `! pool_is_free (smm->wrk[thread_index].sessions, _e)' fails
> 
> So it seems that is currently not possible to use vnet_disconnect_session () 
> from a rx_callback directly.
> 
> Any hints on how to disconnect the tcp session from the rx callback?
> 
> Regards
> Andreas
> 
> 
> Florin
> 
> 
>> On May 17, 2018, at 10:52 PM, muziding > <mailto:muziding...@163.com>> wrote:
>> 
>> Hi
>> 
>> I want to make the example of http server  actively close the client 
>> connection, instead of waiting for the client to close connection, after 
>> http server has responded  to the client request. What should I do?
> 
> _._,_._,_
> Links:
> 
> You receive all messages sent to this group.
> 
> 
> View/Reply Online (#9328) <https://lists.fd.io/g/vpp-dev/message/9328> | 
> Reply To Sender 
> <mailto:fcoras.li...@gmail.com?subject=Private:%20Re:%20Re%3A%20%5Bvpp-dev%5D%20How%20to%20actively%20close%20the%20client%20connections%20in%20http%20server%3F%20%23vnet>
>  | Reply To Group 
> <mailto:vpp-dev@lists.fd.io?subject=Re:%20Re%3A%20%5Bvpp-dev%5D%20How%20to%20actively%20close%20the%20client%20connections%20in%20http%20server%3F%20%23vnet>
>  | Mute This Topic <https://lists.fd.io/mt/19343385/675601> | New Topic 
> <https://lists.fd.io/g/vpp-dev/post>
> 
> 
> 
> Mute #vnet <https://lists.fd.io/mk?hashtag=vnet=1480449>
> 
> Change Your Subscr

Re: [vpp-dev] VPP and TCP half-open connection

2018-11-20 Thread Florin Coras
Hi Rubina, 

That’s a tcp protocol startup configuration parameter that can be used to 
preallocate half-open connections and therefore prevent the underlying pool 
from expanding. It’s especially useful if you expect applications attached to 
vpp’s host stack to open a large number of tcp connections.

Florin 

> On Nov 20, 2018, at 12:29 AM, Andrew Yourtchenko  wrote:
> 
> Hi Rubina,
> 
> Thats host stack - so I will let Florin educate us ! ;)
> 
> --a
> 
> On 20 Nov 2018, at 07:09, Rubina Bianchi  > wrote:
> 
>> Hi Andrew
>> 
>> So what is preallocated-half-open-connections parameters in tcp tag for?
>> 
>> Reference: 
>> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/users/configuring/startup.html
>>  
>> 
>> From: Andrew  Yourtchenko mailto:ayour...@gmail.com>>
>> Sent: Monday, November 19, 2018 5:18 PM
>> To: Rubina Bianchi
>> Cc: vpp-dev@lists.fd.io 
>> Subject: Re: [vpp-dev] VPP and TCP half-open connection
>>  
>> Hi Rubina,
>> 
>> In case the question pertains to transient TCP sessions in ACL plugin - the 
>> answer is no - however a new session takes the least recently used TCP 
>> transient session slot, so there is a natural resource usage balancing.
>> 
>> --a
>> 
>> On 19 Nov 2018, at 14:08, Rubina Bianchi > > wrote:
>> 
>>> Hi Dear VPP
>>> 
>>> Is there any mechanism in VPP to restrict TCP half-open connection count? 
>>> If answer is yes how it can be configured?
>>> 
>>> Thanks,
>>> Sincerely
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#11312): https://lists.fd.io/g/vpp-dev/message/11312 
>>> 
>>> Mute This Topic: https://lists.fd.io/mt/28241090/675608 
>>> 
>>> Group Owner: vpp-dev+ow...@lists.fd.io 
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>>   [ayour...@gmail.com 
>>> ]
>>> -=-=-=-=-=-=-=-=-=-=-=-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11325): https://lists.fd.io/g/vpp-dev/message/11325 
> 
> Mute This Topic: https://lists.fd.io/mt/28241090/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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


Re: [vpp-dev] VPP and TCP half-open connection

2018-11-19 Thread Florin Coras
If your question concerns the host stack, the answer is no.

Florin

> On Nov 19, 2018, at 5:08 AM, Rubina Bianchi  wrote:
> 
> Hi Dear VPP
> 
> Is there any mechanism in VPP to restrict TCP half-open connection count? If 
> answer is yes how it can be configured?
> 
> Thanks,
> Sincerely
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11312): https://lists.fd.io/g/vpp-dev/message/11312 
> 
> Mute This Topic: https://lists.fd.io/mt/28241090/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11316): https://lists.fd.io/g/vpp-dev/message/11316
Mute This Topic: https://lists.fd.io/mt/28241090/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] test-ext failures seen on master

2018-11-16 Thread Florin Coras
I also noticed that although it shouldn’t be different from the vcl test apps 
which seem to be properly killed on test failure. Anyway, it’s on my todo list, 
if nobody beats me to it.

Florin

> On Nov 16, 2018, at 5:27 AM, Klement Sekera  wrote:
> 
> I've also noticed that quite often a binary called sock_test_client is
> left running after a vpp crash or test failure. What's worse, it eats
> 100% CPU.
> 
> Quoting Florin Coras (2018-11-16 00:40:06)
>>   Thanks, Dave!
>>   I’ll take a look at those as soon as I can. I’m running multiple
>>   connections between 2 vpp hosts without issue, so it’s either a
>>   cut-through session issue or it has to do with how we setup vpp for vrf
>>   leaking. 
>>   Cheers,
>>   Florin
>> 
>> On Nov 15, 2018, at 3:00 PM, Dave Wallace <[1]dwallac...@gmail.com>
>> wrote:
>> Same here.  However, in the same workspace where all tests passed, I can
>> get this test case to fail consistently:
>> 
>> EXTENDED_TESTS=y TEST=vcl.VCLThruHostStackExtendedBTestCase.* make test
>> EXTENDED_TESTS=y TEST=vcl.VCLIpv6ThruHostStackExtendedBTestCase.* make
>> test
>> 
>> In patch 13215, I discovered that making these test cases NOT run
>> multiple sockets in parallel the test passes.  My latest patch to that
>> has the multiple sockets option commented out with "# ouch! Host Stack
>> Bug?" so that all tests pass.
>> 
>> Thanks,
>> -daw-
>> On 11/15/2018 4:16 PM, Florin Coras wrote:
>> 
>> That’s an interesting failure. Is the test machine running out of memory?
>> 
>> The extended tests are unstable on my server, so I do see quite a number of 
>> failures. However this:
>> 
>> make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock
>> 
>> runs just fine. After the latest test framework changes, are we running 
>> multiple tests/vpps in parallel? I suspect that may be a source of issues.
>> 
>> Florin
>> 
>> 
>> On Nov 15, 2018, at 12:11 PM, Klement Sekera via Lists.Fd.Io 
>> [2] wrote:
>> 
>> I'm seeing timeouts and coredumps...
>> 
>> e.g.
>> 
>> #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
>> at /home/ksekera/vpp/src/svm/message_queue.h:299
>> 299   return pthread_mutex_trylock (>q->mutex);
>> (gdb) p mq
>> $1 = (svm_msg_q_t *) 0x204009440
>> (gdb) p mq->q
>> $2 = (svm_queue_t *) 0x0
>> 
>> which is part of
>> 
>> #4  
>> #5  __pthread_mutex_trylock (mutex=0x0) at ../nptl/pthread_mutex_trylock.c:39
>> #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
>>at /home/ksekera/vpp/src/svm/message_queue.h:299
>> #7  0x7f9ba04055d5 in svm_msg_q_lock_and_alloc_msg_w_ring 
>> (mq=0x204009440,
>>ring_index=1, noblock=1 '\001', msg=0x7f9b5f7c2a80)
>>at /home/ksekera/vpp/src/svm/message_queue.c:121
>> #8  0x7f9ba14be449 in mq_try_lock_and_alloc_msg (app_mq=0x204009440,
>>msg=0x7f9b5f7c2a80) at 
>> /home/ksekera/vpp/src/vnet/session/session_api.c:407
>> #9  0x7f9ba14be509 in mq_send_session_accepted_cb (s=0x7f9b60351400)
>>at /home/ksekera/vpp/src/vnet/session/session_api.c:432
>> #10 0x7f9ba1496ba0 in application_local_session_connect (
>>client_wrk=0x7f9b60805800, server_wrk=0x7f9b60805780, ll=0x7f9b5f4c9e40,
>>opaque=0) at /home/ksekera/vpp/src/vnet/session/application.c:1646
>> #11 0x7f9ba14a5a62 in application_connect (a=0x7f9b5f7c2d30)
>>at /home/ksekera/vpp/src/vnet/session/application_interface.c:327
>> ---Type  to continue, or q  to quit---
>> #12 0x7f9ba14a69fd in vnet_connect (a=0x7f9b5f7c2d30)
>>at /home/ksekera/vpp/src/vnet/session/application_interface.c:673
>> #13 0x7f9ba14c0f27 in vl_api_connect_sock_t_handler (mp=0x1300a6218)
>>at /home/ksekera/vpp/src/vnet/session/session_api.c:1305
>> #14 0x7f9ba1b6cb25 in vl_msg_api_handler_with_vm_node (
>>am=0x7f9ba1d7dc60 , the_msg=0x1300a6218,
>>vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
>>at /home/ksekera/vpp/src/vlibapi/api_shared.c:502
>> #15 0x7f9ba1b39114 in void_mem_api_handle_msg_i (
>>am=0x7f9ba1d7dc60 , vm=0x7f9ba08fc2c0 ,
>>node=0x7f9b5f7ba000, q=0x13004c440)
>>at /home/ksekera/vpp/src/vlibmemory/memory_api.c:700
>> #16 0x7f9ba1b39183 in vl_mem_api_handle_msg_main (
>>vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
>>at /home/ksekera/vpp/src/vlibmemory/memory_api.c:710
>> #17 0x7f9ba1b572dd in vl_api_clnt_process (
>>vm=0x7f9ba08fc2

  1   2   3   4   >