From: Matan Barak <matanb@mellanox.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Christoph Hellwig <hch@lst.de>
Cc: Parav Pandit <pandit.parav@gmail.com>, Tejun Heo <tj@kernel.org>,
<cgroups@vger.kernel.org>, <linux-doc@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Doug Ledford <dledford@redhat.com>,
Liran Liss <liranl@mellanox.com>,
"Hefty, Sean" <sean.hefty@intel.com>,
Haggai Eran <haggaie@mellanox.com>,
Jonathan Corbet <corbet@lwn.net>, <james.l.morris@oracle.com>,
<serge@hallyn.com>, Or Gerlitz <ogerlitz@mellanox.com>,
Andrew Morton <akpm@linux-foundation.org>,
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
Date: Sun, 11 Sep 2016 11:07:57 +0300 [thread overview]
Message-ID: <ddbb4d5a-c352-925b-c3db-4f33f3e8ac50@mellanox.com> (raw)
In-Reply-To: <20160910170151.GA5230@obsidianresearch.com>
On 10/09/2016 20:01, Jason Gunthorpe wrote:
> On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
>> OFVWG meetings have absolutely zero relevance for Linux development.
>
> Well, to be fair there are a fair number of kernel developers on that
> particular call..
>
>> More "flexibility" for drivers just means giving up on designing a
>> coherent API and leaving it to drivers authors to add crap to their
>> own drivers. That's a major step backwards.
>
> Sadly, it isn't a step backwards, it is status quo - at least as far
> as the uapi is concerned.
>
> Every single user space driver has its own private abi file, carefully
> hidden in their driver, and dutifully copied over to user space:
>
> providers/cxgb3/iwch-abi.h
> providers/cxgb4/cxgb4-abi.h
> providers/hfi1verbs/hfi-abi.h
> providers/i40iw/i40iw-abi.h
> providers/ipathverbs/ipath-abi.h
> providers/mlx4/mlx4-abi.h
> providers/mlx5/mlx5-abi.h
> providers/mthca/mthca-abi.h
> providers/nes/nes-abi.h
> providers/ocrdma/ocrdma_abi.h
> providers/rxe/rxe-abi.h
>
> Just to pick two random examples:
>
> struct mlx5_create_cq {
> struct ibv_create_cq ibv_cmd;
> __u64 buf_addr;
> __u64 db_addr;
> __u32 cqe_size;
> };
>
> struct iwch_create_cq {
> struct ibv_create_cq ibv_cmd;
> uint64_t user_rptr_addr;
> };
>
> Love to hear ideas on a way forward that doesn't involve rewriting
> everything :(
>
Yeah, unfortunately, the RDMA ABI is more driver specific ABI than a
common user-kernel ABI. I guess this will become even worse, as the RDMA
subsystem is evolving to serve more drivers with different object types.
For example, I would like to hear how hfi1 are going to define their
user-kernel ABI (once they leave the custom ioctls).
>> They should not be using the code in drivers/infiniband. usnic is such
>> an example of a driver that should never have been added in it's current
>> form.
>
> +1
>
> Jason
>
Matan
next prev parent reply other threads:[~2016-09-11 8:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-31 8:37 [PATCHv12 0/3] rdmacg: IB/core: rdma controller support Parav Pandit
2016-08-31 8:37 ` [PATCHv12 1/3] rdmacg: Added rdma cgroup controller Parav Pandit
2016-08-31 9:38 ` Leon Romanovsky
2016-09-07 15:07 ` Parav Pandit
2016-09-08 6:12 ` Leon Romanovsky
2016-09-08 10:20 ` Parav Pandit
2016-08-31 15:07 ` Matan Barak
2016-08-31 21:16 ` Tejun Heo
2016-09-01 7:25 ` Matan Barak
2016-09-01 8:44 ` Christoph Hellwig
2016-09-07 7:55 ` Parav Pandit
2016-09-07 8:51 ` Matan Barak
2016-09-07 14:54 ` Parav Pandit
2016-09-10 16:14 ` Christoph Hellwig
2016-09-10 17:01 ` Jason Gunthorpe
2016-09-11 8:07 ` Matan Barak [this message]
2016-09-11 13:34 ` Christoph Hellwig
2016-09-11 14:35 ` Leon Romanovsky
2016-09-11 17:14 ` Jason Gunthorpe
2016-09-11 17:24 ` Christoph Hellwig
2016-09-11 17:52 ` Jason Gunthorpe
2016-09-12 5:07 ` Leon Romanovsky
2016-09-14 7:06 ` Parav Pandit
2016-09-14 8:14 ` Matan Barak
2016-09-14 9:19 ` Parav Pandit
2016-09-15 18:56 ` Leon Romanovsky
2016-09-21 4:43 ` Parav Pandit
2016-09-21 14:26 ` Tejun Heo
2016-09-21 16:02 ` Parav Pandit
2016-10-04 18:19 ` Parav Pandit
2016-10-05 6:37 ` Christoph Hellwig
2016-10-05 11:22 ` Leon Romanovsky
2016-10-05 15:36 ` Tejun Heo
2016-10-06 12:55 ` Parav Pandit
2016-10-18 20:15 ` Parav Pandit
2016-09-19 13:10 ` Dalessandro, Dennis
2016-09-19 17:00 ` Parav Pandit
2016-09-10 16:12 ` Christoph Hellwig
2016-09-11 7:40 ` Matan Barak
2016-08-31 8:37 ` [PATCHv12 2/3] IB/core: added support to use " Parav Pandit
2016-08-31 8:37 ` [PATCHv12 3/3] rdmacg: Added documentation for rdmacg Parav Pandit
2016-08-31 13:56 ` [PATCHv12 0/3] rdmacg: IB/core: rdma controller support Tejun Heo
2016-10-05 11:22 ` Leon Romanovsky
2016-10-06 12:59 ` Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddbb4d5a-c352-925b-c3db-4f33f3e8ac50@mellanox.com \
--to=matanb@mellanox.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dledford@redhat.com \
--cc=haggaie@mellanox.com \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=james.l.morris@oracle.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=liranl@mellanox.com \
--cc=lizefan@huawei.com \
--cc=ogerlitz@mellanox.com \
--cc=pandit.parav@gmail.com \
--cc=sean.hefty@intel.com \
--cc=serge@hallyn.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).