On Thu, Feb 25, 2016 at 12:44:05PM -0800, Andy Zhou wrote: > On Thu, Feb 25, 2016 at 11:40 AM, Ben Pfaff <b...@ovn.org> wrote: > > > On Fri, Feb 19, 2016 at 12:40:19PM -0800, Andy Zhou wrote: > > > Poll group is a new poll class that sits between application and > > > the stream class. Poll group compliments the poll loop facility and the > > > stream class to make main loop more efficient when dealing with > > > large number of current connections. > > > > > > See comments in poll-group-provider.h for more details. > > > > > > Signed-off-by: Andy Zhou <az...@ovn.org> > > > > Usually we build a provider interface when we expect there to be more > > than one implementation on a given platform. For example, netdevs have > > a provider interface because a single system might have system network > > devices, and DPDK network devices, and tunnel network devices, and so > > on. Similarly, dpifs have a provider interface because a single system > > can have netlink and netdev dpifs at the same time. > > > > But in other cases we don't have a provider interface even though there > > is implementation diversity, because a given system has only one > > implementation and we know which one it is at compile time. The daemon and > > latch libraries are examples. > > > > Do we expect there to be more than one implementation of poll groups on > > a given system? > > > I have planed a 'generic' poll group implementation that is not platform > specific. It uses > the same poll group API, but makes changes to poll_block internals to help > deliver changed fd sets. > The 'generic' version is not posted since it will add more infrastructure > changes and epoll() seems > to yield the most benefits for Linux. I should have mentioned about this > in the commit message. > > On the other hand, If we decide to drop the idea of implementing the > 'generic" poll group, then I'd agree > we should also drop the provider API.
We might want both epoll and generic versions, but why would we want to compile both at the same time? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
