From: Stephen Hemminger <hidden> Date: 2017-06-27 22:18:59
On Tue, 27 Jun 2017 20:46:15 +0300
Leon Romanovsky [off-list ref] wrote:
On Tue, Jun 27, 2017 at 11:37:35AM -0600, Jason Gunthorpe wrote:
quoted
On Tue, Jun 27, 2017 at 08:33:01PM +0300, Leon Romanovsky wrote:
quoted
My initial plan was to put all parsers under their respective names, in
the similar way as I did for caps: $ rdma dev show mlx5_4 caps
I think you should have a useful summary display similar to 'ip a' and
other commands.
guid(s), subnet prefix or default gid for IB, lid/lmc, link state,
speed, mtu, pkeys protocol(s)
It will, but before I would like to see this tool be a part of
iproute2, so other people will be able to extend it in addition
to me.
Are you fine with the proposed code?
Output formats need to be nailed down. The output of iproute2 commands is almost
like an ABI. Users build scripts to parse it (whether that is a great idea or not
is debateable, it mostly shows the weakness in programatic API's). Therefore fully
changing output formats in later revisions is likely to get users upset.
The first version doesn't have to be perfect, just close to the overall goal
of what is planned.
From: Leon Romanovsky <hidden> Date: 2017-06-28 04:33:37
On Tue, Jun 27, 2017 at 03:18:59PM -0700, Stephen Hemminger wrote:
On Tue, 27 Jun 2017 20:46:15 +0300
Leon Romanovsky [off-list ref] wrote:
quoted
On Tue, Jun 27, 2017 at 11:37:35AM -0600, Jason Gunthorpe wrote:
quoted
On Tue, Jun 27, 2017 at 08:33:01PM +0300, Leon Romanovsky wrote:
quoted
My initial plan was to put all parsers under their respective names, in
the similar way as I did for caps: $ rdma dev show mlx5_4 caps
I think you should have a useful summary display similar to 'ip a' and
other commands.
guid(s), subnet prefix or default gid for IB, lid/lmc, link state,
speed, mtu, pkeys protocol(s)
It will, but before I would like to see this tool be a part of
iproute2, so other people will be able to extend it in addition
to me.
Are you fine with the proposed code?
Output formats need to be nailed down. The output of iproute2 commands is almost
like an ABI. Users build scripts to parse it (whether that is a great idea or not
is debateable, it mostly shows the weakness in programatic API's). Therefore fully
changing output formats in later revisions is likely to get users upset.
The first version doesn't have to be perfect, just close to the overall goal
of what is planned.
In this version, I'm going to use arrays without indexes, because I prefer
to expose the bare minimum from the kernel, which is RDMA netlink. After
everything else is settled, I'll move those defines to UAPI and reuse them
in rdmatool.
I'll send new version with -d/--details flag and enrich minimal summary.
It won't include anything related to tables gids, pkey yet.
Thanks
From: Jason Gunthorpe <hidden> Date: 2017-06-28 16:11:12
On Tue, Jun 27, 2017 at 03:18:59PM -0700, Stephen Hemminger wrote:
On Tue, 27 Jun 2017 20:46:15 +0300
Leon Romanovsky [off-list ref] wrote:
quoted
On Tue, Jun 27, 2017 at 11:37:35AM -0600, Jason Gunthorpe wrote:
quoted
On Tue, Jun 27, 2017 at 08:33:01PM +0300, Leon Romanovsky wrote:
quoted
My initial plan was to put all parsers under their respective names, in
the similar way as I did for caps: $ rdma dev show mlx5_4 caps
I think you should have a useful summary display similar to 'ip a' and
other commands.
guid(s), subnet prefix or default gid for IB, lid/lmc, link state,
speed, mtu, pkeys protocol(s)
It will, but before I would like to see this tool be a part of
iproute2, so other people will be able to extend it in addition
to me.
Are you fine with the proposed code?
Output formats need to be nailed down. The output of iproute2 commands is almost
like an ABI. Users build scripts to parse it (whether that is a great idea or not
is debateable, it mostly shows the weakness in programatic API's). Therefore fully
changing output formats in later revisions is likely to get users upset.
It would be nice to see an example of what the completed command
should output to make judgements on the format.. Going bit by bit
doesn't really give a full picture, IHO.
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
From: Leon Romanovsky <leon@kernel.org> Date: 2017-06-28 19:11:16
On Wed, Jun 28, 2017 at 10:11:12AM -0600, Jason Gunthorpe wrote:
On Tue, Jun 27, 2017 at 03:18:59PM -0700, Stephen Hemminger wrote:
quoted
On Tue, 27 Jun 2017 20:46:15 +0300
Leon Romanovsky [off-list ref] wrote:
quoted
On Tue, Jun 27, 2017 at 11:37:35AM -0600, Jason Gunthorpe wrote:
quoted
On Tue, Jun 27, 2017 at 08:33:01PM +0300, Leon Romanovsky wrote:
quoted
My initial plan was to put all parsers under their respective names, in
the similar way as I did for caps: $ rdma dev show mlx5_4 caps
I think you should have a useful summary display similar to 'ip a' and
other commands.
guid(s), subnet prefix or default gid for IB, lid/lmc, link state,
speed, mtu, pkeys protocol(s)
It will, but before I would like to see this tool be a part of
iproute2, so other people will be able to extend it in addition
to me.
Are you fine with the proposed code?
Output formats need to be nailed down. The output of iproute2 commands is almost
like an ABI. Users build scripts to parse it (whether that is a great idea or not
is debateable, it mostly shows the weakness in programatic API's). Therefore fully
changing output formats in later revisions is likely to get users upset.
It would be nice to see an example of what the completed command
should output to make judgements on the format.. Going bit by bit
doesn't really give a full picture, IHO.
Bit by bit expansion allow easily control of what is needed. Mostly,
those full examples have nothing close to real use case.