Re: Status of RXE/Soft-RoCE driver?

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

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

On Fri, Apr 29, 2016 at 02:54:34PM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 29, 2016 at 11:06:46AM -0400, Doug Ledford wrote:
> 
> > > These patches are long time here in mailing list and they were reviewed as
> > > all other patches in this mailing list.
> > 
> > That's not true.  The RSS patches in particular tend to get no review.
> > No one appears to care about them.  V1 was posted way back last year and
> > no one had anything to say about them.  I don't know when V2 was, it's
> > no longer in my mailbox.  Then v3 has been on the list for 12 days and
> > again, no one has responded.  No review at all does not mean
> > automatically accepted.
> 
> 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. Liran nominated himself and the OFVWG to act as a
> forum. I recommend we let that process get going and do it's work.
> 
> 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.
> 
> There is more flexability in user space to make mistakes with the
> libibverbs/etc API, and more options to provide access to these kind
> of services. For instance I really wonder if integrating into
> libibverbs is really the right home to trial a broad range of brand
> new UD offload focused features.

Jason,
It is **respin** of patches which were with us for **more than year**, it is
enough time to all participants and maintainer to say their word.

> 
> > >> verbs 2.0 API is settled so we only have one API to apply it too,
> > > 
> > > SELinux code adds hooks which are deep in IB/core code and doesn't
> > > play with ABI at all.
> > 
> > They snoop ABI.  If they ABI changes, they would possibly need to be
> > changed in order to continue to be able to read the elements.
> 
> Agree, if we go to a object based uAPI then there may be better ways
> to make use of selinux right at the uapi layer.

From user perspective, it will be the same, so please name me technical
reason do not proceed with them now.

SELinux patches are contributed by open source company who is actively
supporting IB stack by code and by following IBTA specification.

As I said before and continue to say again, we will invest time and effort to
update all needed pieces of our code to support new ABI whenever it comes.

> 
> Jason

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