On Wed, 2016-06-29 at 08:15 +0300, Leon Romanovsky wrote: > On Tue, Jun 28, 2016 at 03:18:58PM -0600, Jason Gunthorpe wrote: > > On Tue, Jun 28, 2016 at 08:05:49PM +0300, Leon Romanovsky wrote: > > > > > > 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. > > > > Well, I am, I don't know what you are talking about. > > > > > We are talking about the total number of other vendors who will > > > be ready to implement new features exposed in libibverbs. > > > > Who cares? > > > > Mellanox has been pushing dpdk centric HW features that no other > > vendor has an interest in. So it is understandable there is not much > > activity. > > I see it differently, I don't see any activity from other vendors, > because there are no vendors who interest in developing new features in > libibverbs. A fundamental property of good APIs is that they provide a certain degree of stability and backward/forward compatibility. This means (in my view) that for an API which have reached a certain maturity and user base, "default" action should be not to change, and that changes must have compelling arguments. That said, good additions and necessary refactoring is fine, as long as enough care is taken to maintain backward compatibility or a well understood, viable upgrade path for the existing user base. > Currently all vendors can be categorized into three groups: > * Interested in legacy code - a couple of vendors > * Struggling from identity problem (verbs/non-verbs architecture) and > has proprietary library - one vendor > * Interested in developing new features in libibverbs - one vendor I would think that we would want to eventually implement new libibverbs features that makes sense from an application point of view, with priority on those that we believe are most important to our users. My point is just that making changes to libibverbs should be motivated by use cases that cannot be covered by the existing API, or that is clumsy or inefficient or not generic enough, and not be accepted until they have been subject to enough scrutiny to ensure that quality. Through the course of my work with the Infiniband stack so far, I have seen a few cases of changes that were not of that sort, so I appreciate that the community strives to make sure that the "burden of proof" is on the side of those who want changes. Thanks, Knut > > > > However this is an all-vendor software only feature that all HW can > > support right now today, it is fundamentally different than the prior > > HW entangled patches. > > > > Consider the kAPI work to add the new MR stuff that Christoph > > did. That would have been a total disaster if they didn't update all > > the drivers to work with it at the same time. > > > > Userspace is no different, and the responsibility falls with the patch > > author to oversee that process and get it done before merging. > > Again, my response is related to your expectations to see "other > vendors". Please don't drag me to the discussion of Yishai's patches. > > Thanks. > > > > > Jason -- 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
