RE: Upcoming libibverbs release

Steve Wise
2016-06-28T19:12:19Z

> 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.
>

I haven't been following this (long) thread closely enough, but I hope any new
functionality is not _breaking_ existing applications from using _currently
supported_ providers? I thought all this CQ accessor cruft was backwards
compatible. Perhaps I'm wrong?