Hi Murthy, Inline.
> On Mar 16, 2020, at 12:35 AM, Satya Murthy <satyamurthy1...@gmail.com> wrote: > > Hi Florin, > > Over the weekend, I went through the document that you mentioned and it gave > me a good overview. Thanks for pointing to that doc. > However, my task of integrating mqs->epfd into our main dispatch loop still > seems to be needing more finer details of the code. Glad it helped. > > With this respect, I have following few queries. It would be great if you can > help with this. > If this path poses more effort/risk in integration, we may want to switch to > host interface approach ( which has its own issues though :( ) This does need more effort but as long as you understand what you’re doing it should be fine. > > 1) Terminology mapping. > In the VCL application framework, is the following mapping a correct > understanding (with some open items) ? > > TCP-Application => app with a specific client index I’d call the app an application that needs a tcp connection. And yes, it will have a client index in vpp. > Worker => thread in the tcp-application For your use case, yes. New threads are not implicitly mapped to new workers. > Session => tcp end point Session in vcl is equivalent to an fd. The actual tcp endpoint is in the tcp transport layer which sits under the session layer in vpp. > mq in worker => mapped to ? There’s no mapping here. The message queue is the “channel” on which vcl receives io/ctrl notifications from vpp. > mq_evt_conn => mapped to ? Applications don’t have access to this. They only have access to the “mqs epoll fd”, i.e., mqs_epfd. Previously, the workers could’ve had more fds in their mqs_epfd but today we can only have 1, the mq’s eventfd, if one was configured. Initially, this mqs_epfd was used to epoll all of the fds in it, now it’s used to epoll the mq’s eventfd. In the future, this could be converted to a normal fd, but it should be transparent for the app. > > 2) Howcome vppcom_epoll_create is creating a new session. Bit confusing here. That’s like creating a new fd, i.e., you’re given a “session handle” in return. Why would it be confusing? > > 3) Is the TCP server listen_fd also can be integrated into our application > dispatch loop ? Not sure I understood the question. Are you asking if you can integrate a listener fd in a vcl epoll fd? Then, yes. > > 4) How to get hold of mqs->epfd to put into our dispatcher? > I see that the vcl_worker_t is inside vcl_private.c and .h which are not > accessible by the application directly. > Also, i dont see a direct need of having vcl_test_worker* framework in our > app. Hope this is fine. vcl_test_worker is a test toy app, so you really don’t need it. Applications should only use vppcom.h and the function you’re looking for is vppcom_worker_mqs_epfd. That will return the worker’s mqs_epfd which you can afterwards EPOLL_CTL_ADD to your linux epoll fd. > > 5) why can't the TCP application directly use vcl_worker_t data structure ? Because we don’t want applications to interact/depend on vcl internals. Also, the goal with vcl is to have a posix-like api. You should not need more than the session handles and the apis exposed in vppcom.h > > 6) Is there a sample tcp server example that has the server implementation > with linux epoll instead of vppcom_epoll system. A simple one, no, as far as I know. This mechanism was used in the envoy integration done here [1], but that’s not probably the easiest thing to follow. [1] https://github.com/sbelair2/envoy/tree/vpp_integration <https://github.com/sbelair2/envoy/tree/vpp_integration> > > 7) Do you think this approach of integration will be more complex and hence > do you suggest us moving to LDP (or) host interface approach ? > Please let us know. It will be slightly more complicated because you’ll be “manually” tracking the mq’s activity. But in terms of actual extra code needed, you only need to make sure that whenever you get an epoll event on the mqs_epfd, you call vppcom_epoll_wait() with the vcl epoll fd to which you’ve added your app’s sessions (probably including the listen_fd you mentioned above). > > Thanks in advance for your time. Hope it helps. Regards, Florin > > -- > Thanks & Regards, > Murthy
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15791): https://lists.fd.io/g/vpp-dev/message/15791 Mute This Topic: https://lists.fd.io/mt/71899986/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
