> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
