Hi Sastry, Inline.
> On Jun 1, 2021, at 11:48 AM, Sastry Sista <sastry.si...@gmail.com> wrote: > > Hi Florin, > > Thank you for the bit more clarity. I have few > question further to the items: > > 1. In a single worker case, What is the difference between session_handle > from vppcom_session_create and vppcom_epoll_create. The former is a handle that can be connected/listened on while the latter can only be used with vppcom_epoll_wait. > > 2. For every TCP session in a worker, we will have 2 different handlers i.e > vppcom_session_create and vppcom_epoll_create? Or vppcom_epoll_create is > unique for all TCP sessions in a worker? One epoll session handle per worker is typically enough. Session handles that have been connected/accepted can be “added” to an epoll session handle which can afterwards be polled for async events associated to said sessions. This is very similar to linux epoll. > > 3. Is it that vppcom_epoll_create is to handle only control events from memfd > channel and vppcom_session_create is to handle io data message from > particular session? vppcom_epoll_create creates a special session that can be used to asynchronously poll notifications associated to sessions that have been connected/accepted/listened. It’s a general mechanism, not designed for any one use case in particular. Also note that vppcom_epoll_wait can return in, out and hup notifications, so both io and ctrl, not only ctrl. > > 4. Mq_epfd i.e ctrl/io channel is for only notifications? And again control > message we read from rx channel? mq_epfd is an fd that’s used for signaling between vpp and vcl, although note that this is one of two mechanism that can be used to perform this type of signaling. When the message queue vpp uses to send notifications to vcl goes from empty to non-empty state, that fd is written to. So anything that’s waiting for that write event synchronously or asynchronously knows that the message queue has new data. And to stress the point, mq_epfd doesn’t have the data, it’s just a signal that there is data in the message queue (mq). The data, i.e., messages in the message queue, are not directly exposed by vcl to the app. If all sessions connected/accepted/listened are associated to a vppcom_epoll_create() obtained session handle, they can be retrieved using vppcom_epoll_wait. Alternatively, one could use vppcom_select(). > > 5. Example, in case of NON_BLOCKING, we will send CONNECT message and wait > for reply. This reply i.e CONNECTED control message comes on rx (shm) channel? The app does not have access to the shared memory message queue (what you called above rx shm channel). Yes, the connected reply comes there but the app can only retrieve that notification via vppcom_epoll_wait or vppcom_select, as explained above. Regards, Florin > > Could you please help me on these. I hope these will be final. > > With Regards > Sastry > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19519): https://lists.fd.io/g/vpp-dev/message/19519 Mute This Topic: https://lists.fd.io/mt/83043661/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
