epoll's datapath

[rpenaran]

Hi,
I have been focused on the code where we use epoll to get the UDP data from the kernel (linux) when we receive data. I saw that after calling epoll_wait, we read from the UDP buffers in the kernel until the buffer is completely drained (the while(TRUE) in line 1774 in datapath_epoll.c). Does MSQuic do it for any reason? The issue that I'm experiencing is that if you have 2 connections in the same epoll descriptor, you will receive 2 events, but if the first one has a large buffer ready to be read, it will take a long time to switch to the other event (connection). The solution I did for this case is basically to remove this while and do one recvmmsg call per event every time we wake up from epoll_wait. Of course, that means that the events have to be level-triggered. Is there any performance consideration for draining the entire buffer at once (doing that while(TRUE)) that I'm missing?

Thanks!

[thhous-msft]

The whole reason for the while true was because we were using edge triggered epoll events. We actually found last week there is a potential for a race using edge triggered events, so I have an open PR (#2655) to switch to level triggered. Once that got merged, I knew that the while true was a potential issue, so my plan was to remove it and only loop a few times before switching to the next event.

The whole reason for the while true was using edge triggering. Not for performance reasons.

[rpenaran]

Thanks! This clarify my question.