On Thu, Feb 25, 2016 at 12:49 PM, Ben Pfaff <b...@ovn.org> wrote: > 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? >
I was thinking about testing the generic version on Linux, but we can do so with a configuration switch as well. O.K. I will drop the provider interface for poll group. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
