[vpp-dev] Use of cmake breaks builds in master https://gerrit.fd.io/r/#/c/18600/

2019-03-30 Thread Thomas F Herbert

Damjan,

I attempted to fix a problem with use of cmake breaking CentOS builds 
with the patch introduced with the new  rdma-core and quicly driver.


I had this fixed with patch https://gerrit.fd.io/r/#/c/18600/ but it 
wouldn't rebase after another change with quicly.


The patch no longer applies because the quickly.mk in gone and the 
problem appears after a patch of some upstream code. Could you please 
take a look at this:


Submodule path 'deps/picotls': checked out 
'70cd2a60125729f6d6c32c2ace36403b2b6168e6'

--- patching quicly f25b70d37f8974af9cc48a4a565d13a9cdc5fd75
Applying patch: 0001-cmake-install.patch
patching file CMakeLists.txt
patching file deps/picotls/CMakeLists.txt
--- configuring quicly f25b70d37f8974af9cc48a4a565d13a9cdc5fd75 - log: 
/home/therbert/vpp/build-root/rpmbuild/vpp-19.04/build-root/build-vpp-native/external/quicly.config.log
--- building quicly f25b70d37f8974af9cc48a4a565d13a9cdc5fd75 - log: 
/home/therbert/vpp/build-root/rpmbuild/vpp-19.04/build-root/build-vpp-native/external/quicly.build.log

/bin/bash: cmake: command not found
make[5]: *** [packages/quicly.mk:43: 
/home/therbert/vpp/build-root/rpmbuild/vpp-19.04/build-root/build-vpp-native/external/.quicly.build.ok] 
Error 127


Thanks,

--Tom

--
*Thomas F Herbert*
NFV and Fast Data Planes
Networking Group Office of the CTO
*Red Hat*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] IDE for Coding

2019-03-30 Thread Esin Erenoğlu
Hello everyone,

I try to use Netbeans IDE version 8.2 for Vpp coding but I get segmentation
fault when I try to make run with Netbeans. However, when I try to make run
in terminal, everything is okey. So, how can i fix this or which IDE is the
best for Vpp coding?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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