The substitute for epoll would be I/O Completion Ports
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198%28v=vs.85%29.aspx
.
I will be back later on with a patch with this matter.
I have taken your review in account and sent out a new series of patches which
would go more incrementally instead of sending them all in one go(it confused
me also :) ).
Thanks a lot for your time and I would appreciate if you take a look on the new
series of patches.
Kind Regards,
Alin.
________________________________________
From: Ben Pfaff [b...@nicira.com]
Sent: Saturday, July 12, 2014 1:38 AM
To: Alin Serdean
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 03/14] Ignore epoll specific functions in case of
MSVC
On Fri, Jul 11, 2014 at 01:01:26AM +0000, Alin Serdean wrote:
> Bypass epoll_ctl, epoll_create and epoll_wait functions on MSVC.
>
> Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
What's the substitute for these on Windows? Maybe it was supposed to
be in this hunk, which appears incomplete and wrong:
> +#else
> + for (int idx = 0; idx < dpif->uc_array_size; ++idx)
> + {
> + struct dpif_channel *ch =
> &dpif->handlers[handler_id].channels[idx];
> +
> +#endif
This patch looks incomplete otherwise, because I see remaining
references to epoll_fd, e.g. in destroy_all_channels():
close(handler->epoll_fd);
and dpif_linux_recv_wait__():
poll_fd_wait(handler->epoll_fd, POLLIN);
By the way, dpif-linux relies on some properties of epoll that aren't
obtained just by waiting on all the individual fds in place of a
single epoll fd. In particular, if thread A calls
dpif_linux_recv_wait(), then blocks in poll_block() waiting for some
packet to be received, and thread B adds or removes ports, thread A
will wake up for packets received on the *updated* set of ports as
modified by thread B. It gets that "for free" because that's how
epoll sets work.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
