Any clue on this?

From: Shashi Kant Singh
Sent: 06 February 2018 20:00
To: 'Dave Wallace';
Subject: RE: [vpp-dev] epoll conflict

Hi Dave

I am using VPP release 1802. To simplify the question, I ran the standard 
vcl_test_server example and I see that the CPU utilization of that core where 
it is running is always 100%. If I attach gdb I see this

Loaded symbols for /lib64/
0x00007f4abca3f16a in vppcom_epoll_wait (vep_idx=<optimized out>, 
events=events@entry=0x604174 <sock_server_main+20>, 
    wait_for_time=wait_for_time@entry=60) at 
4005                        keep_trying = (clib_time_now (&vcm->clib_time) <= 
timeout) ? 1 : 0;
Missing separate debuginfos, use: debuginfo-install 
(gdb) bt
#0  0x00007f4abca3f16a in vppcom_epoll_wait (vep_idx=<optimized out>, 
events=events@entry=0x604174 <sock_server_main+20>,
    maxevents=maxevents@entry=10, wait_for_time=wait_for_time@entry=60) at 
#1  0x00000000004012a8 in main (argc=<optimized out>, argv=<optimized out>) at 

In the source I see this as
ifdef VCL_TEST
      num_ev = vppcom_epoll_wait (ssm->epfd, ssm->wait_events,
                                  SOCK_SERVER_MAX_EPOLL_EVENTS, 60.0);
      if (num_ev < 0)
        errno = -num_ev;

My question would be, if this is a epoll_wait call, why would I see CPU 
utilization of 100%. Even if I make it a blocking call by setting timeout to 
-1, I still see it to be 100%. Please help me understand this


[] On Behalf Of Dave Wallace
Sent: 06 February 2018 19:23
Subject: Re: [vpp-dev] epoll conflict


Can you elaborate on your use case?  There's really not enough information to 
understand what you're trying to accomplish to know how to help.

Assuming that you are using LD_PRELOAD to "link the vcom library to the 
application", the vcom api layer redirects calls based on the fd to either 
vppcom or libc.

Also what version of the code are you running?

You should be aware that VCL/LD_PRELOAD is still largely experimental and under 
development.  There are many features of the posix socket interface which are 
missing or have stub implementations.  Development of VCL to date has been 
entirely use-case driven.

On 02/06/2018 04:39 AM, Shashi Kant Singh wrote:

I have a linux application which uses native kernel epoll_wait calls. I needed 
to add a new thread in that application which is a VPP based thread i.e. it 
uses DPDK to send and receive on additional igb_uio ports. For this I had to 
link the vcom library to the application and now I see that epoll used by all 
linux application is from vcom. How do I separate out linux thread from VPP 
thread to use corresponding epoll libraries


#0  0x00007f2c2c592482 in clib_spinlock_lock (p=0x7f2c1a82c030) at 
#1  vppcom_epoll_wait (vep_idx=vep_idx@entry=3, 
events=events@entry=0x7f2bd40013c0, maxevents=maxevents@entry=10,
    wait_for_time=wait_for_time@entry=0) at 
#2  0x00007f2c2c580dec in vcom_socket_epoll_pwait (__epfd=22, 
__events=0x7f2bd40013c0, __maxevents=10, __timeout=-1, __ss=0x0)
    at /bng5/vbbu10/vpp2/vpp/build-data/../src/vcl/vcom_socket.c:3045
#3  0x00007f2c2c57c298 in epoll_wait (__epfd=22, __events=0x7f2bd40013c0, 
__maxevents=10, __timeout=-1)
    at /bng5/vbbu10/vpp2/vpp/build-data/../src/vcl/vcom.c:2869
#4  0x00007f2c2f628aa0 in RMAMessageThreadPosix::receive_message_impl 
(arg=0x1cf0a10) at src/rma_message_thread_posix.cpp:789
#5  0x00007f2c2dacbe25 in start_thread () from /lib64/
#6  0x00007f2c2b3c434d in clone () from /lib64/


vpp-dev mailing list<>

Reply via email to