Re: [RFC] rdma/uverbs: Sketch for an ioctl framework

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

On Tue, May 24, 2016 at 01:57:54PM -0400, Doug Ledford wrote:

> Sean's proposal does away with the rigid nature of the current verbs 1.0
> API and makes it much more flexible on a per-driver basis.  This doesn't
> address the end user API issues, but it at least cleans up the user
> driver <-> kernel driver API so that one vendor's driver is not forced
> to carry around all the baggage needed for every other vendor's drivers.

I'm not sure what you are reading, but to me both proposals look very
similar. They are both based on the generic object/action/method sort
of model I talked about in an earlier thread.

The main differences seem to boil down to the data marshalling and the
dispatching style for the kernel side..

Sean hasn't explored how to encode the actual method arguments, while
Mellanox's has a fairly well developed scheme with the netlink
encoding and sgl result list thingy.

> Under that model, each vendor only carries what they need.  It would
> then be libibverbs responsibility to take that driver specific data
> and

Either patchset could go in this direction. This is a basic question
we need to decide on.

I'm starting to think the basic thrust of the Mellanox series (provide
an easy compatability with our userspace) is a sane approach. The
other options look like far too much work to use as a starting point.

That doesn't mean we can't decide to move in a direct-only direction -
the uAPI needs to have enough extension points to allow for that. Such
work should happen incrementally, and mainly target new uAPIs.

> and not also the user visible libibverbs API at the same time.  If all
> we want to talk about is verbs 1.0 over ioctl, then yes, we can do that.
>  But not if we truly want to discuss a verbs 2.0 API.  And I have yet to
> gather from the discussions I hear from people that we are in fact
> decided on pursuing a verbs 1.0 over ioctl API instead of considering a
> verbs 2.0 API.

You are the only person I've heard who wants to restructure the
libibverbs interface at the same time..

When I kicked off this process at the OFA meeting the discussions
revolved around some very clear goals:
 1) Comprehensively close the security issue
 2) Provide 100% support for existing libibverbs users on the current
    libibverbs API
 3) Restructure obvious known weaknesses (eg IB specific areas)
 4) Add additional extension points

I feel like both patches are still going down the above path..

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