On Tue, Jun 28, 2016 at 10:20:28AM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 28, 2016 at 08:02:46AM +0300, Leon Romanovsky wrote:
> > On Mon, Jun 27, 2016 at 12:17:58PM -0600, Jason Gunthorpe wrote:
> > > Doug and I have both stated we don't want to see so many
> > > single-provider APIs and churn in libibverbs. This was designed to be
> > > a generic API that all providers can implement.
> > > 
> > > The responsibility falls on you to make sure that it works
> > > universally. Compat is one option.
> > > 
> > > This is also why it is necessary to get the other provider authors to
> > > say this works on their hardware, because they *all* ultimately have
> > > to implement it.
> > > 
> > > I don't think many people realize this yet.
> > > 
> > 
> > Jason,
> > You are over-estimating the number of other providers who are
> > interesting in libibverbs in 2014-2016.
> 
> I don't think that is a reasonable metric, verbs is stable, I don't
> expect companies to be constantly churning it.
> 
> And that certainly doesn't mean we should abandon their providers when
> building new APIs.
> 
> However, if that is your position then propose a patch so libibverbs
> with the new polling API will not load old providers that do not
> support it, and they can be deprecated. If their authors don't object,
> like you predict, then great.
> 
> But at the end of the day, the message to users must be to use the
> new polling API, the old one is deprecated, and apps should never
> include fallback code because the new API always works.

Please put aside Yishai's patches, I'm not taking about them.

We are talking about the total number of other vendors who will
be ready to implement new features exposed in libibverbs.

Git log perfectly supports my claim that this number is extremely low.

> 
> Jason