From: Leon Romanovsky <hidden> Date: 2017-05-04 18:02:08
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
----
This is initial phase to understand if user experience for this tool fits
RDMA and netdev communities exepectations. Also I would like to get feedback
if it is really worth to provide legacy sysfs for old kernels, or maybe I should
implement netlink from the beginning and abandon sysfs completely.
-----
Hi,
Please find below, the patch set with initial implementation of configuration
tool for RDMA subsystem, which will be supplementary tool to already existed
tools in netdev community (ip, devlink, ethtool, ..).
In opposite to netdev community, where standard tools exist to configure and
present different devices abilities, RDMA subsystem historically lacked it.
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
The development of tool was influenced by ip and devlink tools. This implies
to the object->command interface and naming convention.
In order to close object model, ensure reuse of existing code and make this
tool usable from day one, we decided to implement wrappers over legacy sysfs
prior to implementing netlink functionality. As a nice bonus, it will allow
to use this tool with old kernels too.
It is important to mention that any future extension will be required to be
done with netlink, so for already existing objects small conversion to netlink
will be unavoidable.
# rdma -h
Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
where OBJECT := { dev | link | ipoib | memory | stats | protocols | providers | monitor }
OPTIONS := { -V[ersion] }
* DEV object equals to CA in IBTA specification and will provide
a way to configure/present settings relevant to specific struct ib_device.
* LINK object represents port in IBTA specification and will give access to
struct ib_port_immutable. From the day one, It prints netdev name of
the corresponding IB port that makes ibdev2netdev script redundant.
* IPoIB object is supposed to be specific for IP-over-Infiniband upper
layer protocol [3]. This ULP was mainly configured by combination
of various sysfs knobs together with ethtool. Such situation adds
challenges to add new and expose old configuration settings due to
the mix between different subsystems.
* MEMORY object will be used to configure memory related settings,
e.g. on-demand-paging (ODP), force-mr (force usage of MRs for
RDMA READ/WRITE operation).
* STATS object is needed for everything related to statistics
(per-PID, per-QP, per-device etc.). Despite the fact that RDMA
devices provide extensive set of counters, the decision was to
implement it in netlink directly, because there is a need to add
filter mechanism to them, which doesn't exist now.
* PROTOCOLS object is going to be used for device special treatment
of global to protocol settings (e.g. set device in RoCEv2 mode as
a default, instead of RoCEv1, instead of configfs).
* PROVIDERS objects gives ability to get specific to the device
information, like supported kABI objects [4].
* MONITOR object is needed to debug netlink communication and will
follow standard functionality, which exists in ip and devlink tools.
There are number of ULPs which are not covered by this tool yet:
* HFI-VNIC - I have no access to the HW and believe that Intel
will add native object support for it.
* Other storage related ULPs (iSER and SRP) were not introduced too,
because they have special tools (scci-target-utils) to configure them.
However it will be pretty straightforward to introduce new object,
if there is demand for it.
At the initial stage, we implemented infrastructure to read legacy
sysfs entries (Patch #1), initial man pages (Patch #7) and provided
future object examples (Patch #2-6) to allow parallel development.
Following patches will focus on cleaning user interface, parsing other
relevant entries in similar fashion to the link capability mask (Patch #8)
and providing netlink interface.
These patches were tested with two following setups:
* Setup A:
- Two Mellanox ConnectX-4 devices (one port)
- One Mellanox Connect-IB device (two ports)
* Setup B:
- One Mellanox ConnectX-4 device (one port)
- One Mellanox ConnectX-3 Pro device (two ports)
Please consider the inclusion of the RDMA tool into iproute2 package,
so other participants will be able to speed up development.
[1] https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg148523.html
[2] http://www.medkio.com/talks/lpc_debug.pdf
[3] https://tools.ietf.org/html/rfc4392
[4] http://marc.info/?l=linux-rdma&m=149261526916544&w=2
TODO: Add json output
Cc: Stephen Hemminger <redacted>
Cc: Doug Ledford <redacted>
Cc: Jiri Pirko <jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Ariel Almog <ariela-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Dennis Dalessandro <redacted>
Cc: Ram Amrani <ram.amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Cc: Bart Van Assche <redacted>
Cc: Sagi Grimberg <redacted>
Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Christoph Hellwig <redacted>
Cc: Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Linux RDMA <redacted>
Cc: Linux Netdev <redacted>
Leon Romanovsky (8):
rdma: Add basic infrastructure for RDMA tool
rdma: Add dev object
rdma: Add link object
rdma: Add IPoIB object
rdma: Add memory object
rdma: add stubs for future objects
man: rdma.8: Document objects and commands
rdma: Add link capability parsing
Makefile | 2 +-
man/man8/Makefile | 3 +-
man/man8/rdma.8 | 109 +++++++++++++++++++
rdma/.gitignore | 1 +
rdma/Makefile | 15 +++
rdma/dev.c | 101 ++++++++++++++++++
rdma/ipoib.c | 54 ++++++++++
rdma/link.c | 160 ++++++++++++++++++++++++++++
rdma/memory.c | 30 ++++++
rdma/monitor.c | 22 ++++
rdma/protocols.c | 22 ++++
rdma/providers.c | 28 +++++
rdma/rdma.c | 104 ++++++++++++++++++
rdma/rdma.h | 93 ++++++++++++++++
rdma/stats.c | 22 ++++
rdma/utils.c | 313 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
16 files changed, 1077 insertions(+), 2 deletions(-)
create mode 100644 man/man8/rdma.8
create mode 100644 rdma/.gitignore
create mode 100644 rdma/Makefile
create mode 100644 rdma/dev.c
create mode 100644 rdma/ipoib.c
create mode 100644 rdma/link.c
create mode 100644 rdma/memory.c
create mode 100644 rdma/monitor.c
create mode 100644 rdma/protocols.c
create mode 100644 rdma/providers.c
create mode 100644 rdma/rdma.c
create mode 100644 rdma/rdma.h
create mode 100644 rdma/stats.c
create mode 100644 rdma/utils.c
--
2.12.2
--
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
@@ -0,0 +1,112 @@+/*+*link.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++staticintlink_help(structrdma*rd)+{+pr_out("Usage: %s link show [ DEV | DEV/PORT ]\n",rd->filename);+pr_out(" %s link set DEV/PORT { type { eth | ib | auto } |\n",rd->filename);+pr_out(" lb_unicast { on | off } |\n");+pr_out(" lb_multicast { on | off } }\n");+return0;+}++staticvoiddev_one_show(conststructdev_map*dev_map,uint32_tport_idx_first,uint32_tport_idx_last)+{+char*nodes[]={"cap_mask",+"lid",+"lid_mask_count",+"link_layer",+"phys_state",+"rate",+"sm_lid",+"sm_sl",+"state",+NULL};++structport_map*port_map;+chardata[4096];+inti,j;++for(j=port_idx_first;j<=port_idx_last;j++){+pr_out("%u/%u: %s/%u:",dev_map->idx,j,dev_map->dev_name,j);+list_for_each_entry(port_map,&dev_map->port_map_list,list)+if(j==port_map->idx)+printf(" ifname %s",(port_map->ifname)?:"NONE");++for(i=0;nodes[i];i++){+if(rdma_sysfs_read_ib(dev_map->dev_name,j,nodes[i],data))+continue;++/* Split line before "phys_state" */+if(!strcmp(nodes[i],"phys_state"))+printf("\n\t");++pr_out(" %s %s",nodes[i],data);+}+pr_out("\n");+}+}++staticintlink_show(structrdma*rd)+{+structdev_map*dev_map;++if(rd_no_arg(rd)){+list_for_each_entry(dev_map,&rd->dev_map_list,list)+dev_one_show(dev_map,1,dev_map->num_ports);+}+else{+uint32_tport_idx;+uint32_tnum_ports;+dev_map=dev_map_lookup(rd,true);+port_idx=get_port_from_argv(rd);+if(!dev_map||port_idx>dev_map->num_ports){+pr_err("Wrong device name\n");+return-EINVAL;+}+if(port_idx)+num_ports=port_idx;+else{+port_idx=1;+num_ports=dev_map->num_ports;+}++dev_one_show(dev_map,port_idx,num_ports);+}+return0;+}++staticintlink_set(structrdma*rd)+{+/* Not supported yet */+return0;+}++intobj_link(structrdma*rd)+{+conststructrdma_objobjs[]={+{NULL,link_show},+{"show",link_show},+{"list",link_show},+{"set",link_set},+{"help",link_help},+{0}+};++if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++returnrdma_exec_cmd(rd,objs,"link command");+}
@@ -0,0 +1,101 @@+/*+*dev.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++staticintdev_help(structrdma*rd)+{+pr_out("Usage: %s dev show [DEV]\n",rd->filename);+pr_out(" %s dev set DEV [ node_desc { DESCRIPTION } ]\n",rd->filename);+/* Add masking of device capabilities */+return0;+}++staticvoiddev_one_show(conststructdev_map*dev_map)+{+char*nodes[]={"board_id",+"fw_pages",+"fw_ver",+"hca_type",+"hw_rev",+"node_desc",+"node_guid",+"node_type",+"reg_pages",+"sys_image_guid",+/* hfi1 specific */+"nctxts",+"nfreectxts",+"serial",+"boardversion",+"tempsense",+NULL};++chardata[4096];+inti;+pr_out("%u: %s:",dev_map->idx,dev_map->dev_name);+for(i=0;nodes[i];i++){+if(rdma_sysfs_read_ib(dev_map->dev_name,0,nodes[i],data))+continue;++/* Split line before "node_desc" */+if(!strcmp(nodes[i],"node_desc")||+!strcmp(nodes[i],"sys_image_guid"))+printf("\n\t");++pr_out(" %s %s",nodes[i],data);+}+pr_out("\n");+}++staticintdev_show(structrdma*rd)+{+structdev_map*dev_map;++if(rd_no_arg(rd)){+list_for_each_entry(dev_map,&rd->dev_map_list,list)+dev_one_show(dev_map);+}+else{+dev_map=dev_map_lookup(rd,false);+if(!dev_map){+pr_err("Wrong device name\n");+return-ENOENT;+}+dev_one_show(dev_map);+}+return0;+}++staticintdev_set(structrdma*rd)+{+/* Not implemented yet */+return0;+}++intobj_dev(structrdma*rd)+{+conststructrdma_objobjs[]={+{NULL,dev_show},+{"show",dev_show},+{"list",dev_show},+{"set",dev_set},+{"help",dev_help},+{0}+};++if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++returnrdma_exec_cmd(rd,objs,"dev command");+}
From: Leon Romanovsky <leon@kernel.org> Date: 2017-05-04 18:02:34
From: Leon Romanovsky <redacted>
Memory object gives to the user ability to manipulate over general
properties of memory for the specific devices. The memory properties
have broader usage than dev object can provide.
For example, on-demand-paging (ODP) configurations are mostly software related.
Signed-off-by: Leon Romanovsky <redacted>
---
rdma/Makefile | 2 +-
rdma/memory.c | 30 ++++++++++++++++++++++++++++++
rdma/rdma.c | 3 ++-
rdma/rdma.h | 1 +
4 files changed, 34 insertions(+), 2 deletions(-)
create mode 100644 rdma/memory.c
@@ -0,0 +1,30 @@+/*+*memory.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++staticvoidmemory_help(char*filename)+{+pr_out("Usage: %s memory show [ DEV ]\n",filename);+pr_out(" %s memory set DEV { odp { off | on } |\n",filename);+pr_out(" %s memic SIZE }\n",filename);+}++intobj_memory(structrdma*rd)+{+if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++memory_help(rd->filename);+return0;+}
From: Leon Romanovsky <leon@kernel.org> Date: 2017-05-04 18:02:44
From: Leon Romanovsky <redacted>
The following objects (monitor, providers, stats and protocols) are not
implemented yet, however it is worth to place their stubs in the code.
This will serve as an initial starting point for other developers to
extend RDMA tool.
Signed-off-by: Leon Romanovsky <redacted>
---
rdma/Makefile | 2 +-
rdma/monitor.c | 22 ++++++++++++++++++++++
rdma/protocols.c | 22 ++++++++++++++++++++++
rdma/providers.c | 28 ++++++++++++++++++++++++++++
rdma/rdma.c | 6 +++++-
rdma/rdma.h | 4 ++++
rdma/stats.c | 22 ++++++++++++++++++++++
7 files changed, 104 insertions(+), 2 deletions(-)
create mode 100644 rdma/monitor.c
create mode 100644 rdma/protocols.c
create mode 100644 rdma/providers.c
create mode 100644 rdma/stats.c
@@ -0,0 +1,22 @@+/*+*monitor.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++intobj_monitor(structrdma*rd)+{+if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++return0;+}
@@ -0,0 +1,22 @@+/*+*protocols.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++intobj_protocols(structrdma*rd)+{+if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++return0;+}
@@ -0,0 +1,28 @@+/*+*providers.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++staticvoidproviders_help(char*filename)+{+pr_out("Usage: %s providers show [ DEV ]\n",filename);+}++intobj_providers(structrdma*rd)+{+if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++providers_help(rd->filename);+return0;+}
@@ -0,0 +1,22 @@+/*+*stats.cRDMAtool+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*+*Authors:LeonRomanovsky<leonro@mellanox.com>+*/++#include"rdma.h"++intobj_stats(structrdma*rd)+{+if(dev_map_init(rd)){+pr_err("There are no RDMA devices\n");+return-ENOENT;+}++return0;+}
From: Bart Van Assche <hidden> Date: 2017-05-04 18:10:59
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Hello Leon,
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
Thanks,
Bart.
From: Leon Romanovsky <leon@kernel.org> Date: 2017-05-04 18:25:37
On Thu, May 04, 2017 at 06:10:54PM +0000, Bart Van Assche wrote:
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
quoted
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Hello Leon,
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
We are planning to reuse the same infrastructure provided by iproute2,
like netlink parsing, access to distributions, same CLI and same standards.
Right now, RDMA is already tightened to netdev: iWARP, RoCE, IPoIB, HFI-VNIC.
Many drivers (mlx, qed, i40, cxgb) are sharing code between net and
RDMA.
I do expect that iproute2 will be installed on every machine with any
type of connection, including IB and OPA.
So I think that it is enough to be part of that suite and don't invent
our own for one specific tool.
Thanks
Thanks,
Bart.--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche@sandisk.com wrote:
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
quoted
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Hello Leon,
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
Bart, please realize that iproute2 is much more than "*IP routing* tool".
I understand you got confused by the name. Please see sources. Your comment
is totally pointless...
From: Bart Van Assche <hidden> Date: 2017-05-06 14:40:24
On Sat, 2017-05-06 at 12:40 +0200, Jiri Pirko wrote:
Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche@sandisk.com wrote:
quoted
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
quoted
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
Bart, please realize that iproute2 is much more than "*IP routing* tool".
I understand you got confused by the name. Please see sources. Your comment
is totally pointless...
I asked for a clarification that should have been in the cover letter but that
was missing from that cover letter. So I think that was the right thing to do
instead of pointless. BTW, can you explain why you are using an e-mail address
that is hiding that you are a Mellanox employee?
Bart.N�����r��y���b�X��ǧv�^�){.n�+����{��ٚ�{ay�
ʇڙ�,j��f���h�����/oSc��ڳ9�u�����&jw��(�階�ݢj"���m�����z�ޖ���f���h���~�m�
Sat, May 06, 2017 at 04:40:24PM CEST, Bart.VanAssche@sandisk.com wrote:
On Sat, 2017-05-06 at 12:40 +0200, Jiri Pirko wrote:
quoted
Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche@sandisk.com wrote:
quoted
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
quoted
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
Bart, please realize that iproute2 is much more than "*IP routing* tool".
I understand you got confused by the name. Please see sources. Your comment
is totally pointless...
I asked for a clarification that should have been in the cover letter but that
was missing from that cover letter. So I think that was the right thing to do
I think that was just complete misunderstanding about what iproute2 is.
instead of pointless. BTW, can you explain why you are using an e-mail address
that is hiding that you are a Mellanox employee?
From: Leon Romanovsky <hidden> Date: 2017-05-07 21:46:30
On Sat, May 06, 2017 at 02:40:24PM +0000, Bart Van Assche wrote:
On Sat, 2017-05-06 at 12:40 +0200, Jiri Pirko wrote:
quoted
Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche@sandisk.com wrote:
quoted
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
quoted
Following our discussion both in mailing list [1] and at the LPC 2016 [2],
we would like to propose this RDMA tool to be part of iproute2 package
and finally improve this situation.
Although I really appreciate your work: can you clarify why you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't found any motivation
for adding RDMA functionality to iproute2 in [1].
Bart, please realize that iproute2 is much more than "*IP routing* tool".
I understand you got confused by the name. Please see sources. Your comment
is totally pointless...
I asked for a clarification that should have been in the cover letter but that
was missing from that cover letter. So I think that was the right thing to do
instead of pointless. BTW, can you explain why you are using an e-mail address
that is hiding that you are a Mellanox employee?
For the same reason as I do. It is much easier to use outside servers
than Mellanox's IT infrastructure.
Right now, I'm speaking for myself, but for me, to properly answer with @mellanox.com,
I need to use very specific mail setup, while for any other addresses I can and use any
sane setup, including mobile application.