On Aug 13, 2014, at 8:16 AM, Alin Serdean <aserd...@cloudbasesolutions.com> wrote:
> The following changes are just a start to begin a discussion. > > Bypass all epoll functionality. > > IOCP work the other way around than epoll: you get if the operation finished > for a HANDLE in contrast of getting the number of file descriptors that are > ready for an operation. Agree, IOCP is not directly compatible with epoll. Like, it has been discussed earlier, there's a way to make the IOCP work with the recv_set, recv_wait, recv workflow. We can discuss more on this. But, as you say, we may not be able to make it compatible with epoll. > It also adds a lot of overhead for our particular task. What overhead are you implying? > The nl_sock_recv in dpif_linux_recv__ can be flagged to get the > GetOverlappedResult for that specific handle if needed. In dpif-windows.c, we actually pass the overlapped structure to the poll infrastructure. WaitForMultipleObjects() can be used on the event in the overlapped structure. When the IRP is completed by the userspace, the poll fires. It might be possible to use GetOverlappedResult() to get the same effect, but then you'll have to do busy polling in recv_wait(), and return 0. > Initialize dpif_linux_class on MSVC as well. Sounds good. As has been discussed, maybe we should make the linux -> netdev changes first, and then the excluding epoll from _WIN32 changes on top of that. thanks, Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
