[ovs-dev] [poll group RFC 1/6] lib: Introduce poll group provider class

[Ben Pfaff]

On Thu, Feb 25, 2016 at 12:44:05PM -0800, Andy Zhou wrote:
> On Thu, Feb 25, 2016 at 11:40 AM, Ben Pfaff <blp at 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 <azhou at 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?