Message-ID: <20170118173327.GF32481@mtr-leonro.local>
Date:   Wed, 18 Jan 2017 19:33:27 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Ariel Almog <arielalmogworkemails@...il.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC] RESEND - rdmatool - tool for RDMA users

On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote:
> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
> <arielalmogworkemails@...il.com> wrote:
> > General
> > *******
> > As of today, there is no single, simple, tool that allows monitoring
> > and configuration of RDMA stack.
>
> Before tool, what kernel UAPI you thought to use?

I'm aware of the following options:
1) netlink
2) RDMA ABI https://www.spinics.net/lists/linux-rdma/msg43960.html
3) ioctl
4) write/read

The items 1 and 2 are preferred options and one of the main goals
for this RFC is to chose between them.

For example, RDMA ABI has native support of querying and discovering
device capabilities via merge tree feature.
https://github.com/matanb10/linux/commit/61aaa4cae1281f6bb32e261f0b8aad489db764ac

>
>
> > rdmatool will provide standard, provider agnostic, user interface.
> > RDMA user can use this interface to
> > * Query RDMA device capabilities
> > * Query RDMA device status and current open resources
> > * Fetching RDMA statistics
> > * Configure RDMA device
> >
> > The rdmatool will have the ability to control RDMA stack which
> > includes the ib_device and RDMA protocol params.
> >
> > It is a good point to highlight the similarity to ethtool. It manages
> > net_device, while rdmatool will manage RDMA stack.
> >
> > As a proposal, it is appealing to have a similar design to ethtool for
> > rdmatool too. As ethtool, it should contain user space part, kernel
> > handler and vendor specific handler(s).
> >
> > Another tool which allows similar functionality is iproute2. Iproute2
> > allows user space tools to configure and query transport, network and
> > link layer. The advantages of using iproute2 is the reuse of existing
> > tool and familiar interface in addition to the wide spreading of this tool.
> >
> > As start point of the discussion, we would like to propose two
> > implementation options for the rdmatool:
> > (1) Build a tool using ABI interface. This will be a RDMA tool
> >     which will be distributed as part of RDMA package
> > (2) Enhancing iproute2 to include rdmatool functionality
> >
> > Our opinion is that the new ABI interface provides vast functionality and
> > it will be a waste to use other interface for the same functionality.
> > Each of the proposed implementation above have their advantages, and we
> > would like to hear your opinion regarding this direction.
>
> > I’m posting this RFC in both netdev and linux-rdma communities in
> > order to get feedback on this topic.
>
> What's wrong with the RDMA netlink infrastructure?! it's there for
> years and used
> for various cases by MLNX, did you look on the code?

Nothing wrong, it is one of the valuable options and will be used if
community decides to put this tool under iproute2/ethtool umbrella.

>
> cea05ea IB/core: Add flow control to the portmapper netlink calls
> ae43f82 IB/core: Add IP to GID netlink offload
> 2ca546b IB/sa: Route SA pathrecord query through netlink
> 753f618 RDMA/cma: Add support for netlink statistics export
> b2cbae2 RDMA: Add netlink infrastructure

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists