Re: Status of RXE/Soft-RoCE driver?

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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.

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

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