Re: Status of RXE/Soft-RoCE driver?

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

On Mon, May 02, 2016 at 06:29:38PM +0000, Hefty, Sean wrote:
> > During the Collab summit I thought we reached a rough consensus that
> > these sorts of uAPI changes to the common multi-vendor API would go
> > through a more rigorous process and those who are proposing them would
> > actively seek a multi-vendor sign off instead of simply dumping them
> > on the list.
> 
> I agree that this is the right approach to follow.  A Linux maintainer should not be in the position of having to decide on which features merit a uAPI change.

In this specific case, all guides were followed.

> 
> > Further, I also thought we reached a rough consensus that we'd shunt
> > some of this stuff to the driver specific uAPI channel to reduce this
> > continual churn on the common multi-vendor API for currently
> > driver-specific features. Drivers can implement their unique features
> > and sanely export them through the kernel without so much pain. The
> > uAPI 2.0 concepts from all parties have been heavily influenced by
> > this idea.
> > 
> > Certainly, if patches cannot attract any review or interest from the
> > community as part of the core API then I'd say that is an excellent
> > sign they should be shunted to a driver specific channel.
> 
> This is an excellent point.  The lack of interest is likely a very good sign that this is a driver specific feature.

I don't agree with that point, the lack of discussion doesn't mean that
this is driver specific feature. In linux-rdma community, there is a small
amount of developers focused on their products and maintainer who doesn't
express his opinion.

There is general agreement that Mellanox is a leading provider of IB solutions
and as a leader it's expected from the company to propose new exciting
features which are valuable for the community (general API) and for the
customers.

In this particular case (RSS), we followed **all** possible guidelines of
presenting, discussing and adjusting. It was done in **all** available
forums (linux-rdma, OFA and OFVWG).

We did it openly without any hiding under "proprietary umbrella", as
other companies did during review feedback.

> 
> I'm not sure why there seems to be objection to calling out driver specific features as driver specific and exposing them as such.  It seems like the quickest way to get features into the hands of prospective users.

We want it beneficial to all participants without proprietary stuff.
We don't want to see vendor interfaces proposed and implemented without
any review as it was for several drivers in RDMA world.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]