Re: [PATCH iproute2 3/5] rdma: Add device capability parsing

2 messages, 2 authors, 2017-06-26 · open the first message on its own page

Re: [PATCH iproute2 3/5] rdma: Add device capability parsing

From: Leon Romanovsky <hidden>
Date: 2017-06-26 19:21:03

On Mon, Jun 26, 2017 at 12:29:24PM -0600, Jason Gunthorpe wrote:
On Mon, Jun 26, 2017 at 09:21:26PM +0300, Leon Romanovsky wrote:
quoted
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Add parsing interface for the device capability flags

$ rdma dev show
1: mlx5_0: caps 0x1257e1c26
This seems very un ip-like. I wouldn't show an undecoded hex value
like that, it isn't really useful.
It is first supported field, after new fields will be added, we will
have very similar to ip interface.

1: mlx5_0: caps 0x1257e1c2 key_1 val_1 key_2 val_2 ....

The value are presented as is can be usable as an input for different scripts.
quoted
$ rdma dev show mlx5_4 caps
5: mlx5_4: caps 0x1257e1c26
Bit	Description
 01	DEVICE_BAD_PKEY_CNTR
 02	DEVICE_BAD_QKEY_CNTR
This table also seems un ip-like, the usual format is a list of words,
I think.
It is true for key<->value data, but it is less obvious for bit parsing.
Internally, I tried to present them as list and it was ugly like hell
without any chance (without extra parsing) to actual see if specific
capability is present or no.

The question is: is such presentation usable and does it make sense?
quoted
$ rdma dev show mlx5_4 cap_flags
Unknown parameter 'caps_flags'.
?
An example of "wrong" parameter. There is no such caps_flags.
Jason

Re: [PATCH iproute2 3/5] rdma: Add device capability parsing

From: Jason Gunthorpe <hidden>
Date: 2017-06-26 20:36:25

On Mon, Jun 26, 2017 at 10:21:03PM +0300, Leon Romanovsky wrote:
On Mon, Jun 26, 2017 at 12:29:24PM -0600, Jason Gunthorpe wrote:
quoted
On Mon, Jun 26, 2017 at 09:21:26PM +0300, Leon Romanovsky wrote:
quoted
From: Leon Romanovsky <redacted>

Add parsing interface for the device capability flags

$ rdma dev show
1: mlx5_0: caps 0x1257e1c26
This seems very un ip-like. I wouldn't show an undecoded hex value
like that, it isn't really useful.
It is first supported field, after new fields will be added, we will
have very similar to ip interface.

1: mlx5_0: caps 0x1257e1c2 key_1 val_1 key_2 val_2 ....

The value are presented as is can be usable as an input for different scripts.
I still wouldn't show an undecoded hex value.. It isn't useful.
quoted
quoted
$ rdma dev show mlx5_4 caps
5: mlx5_4: caps 0x1257e1c26
Bit	Description
 01	DEVICE_BAD_PKEY_CNTR
 02	DEVICE_BAD_QKEY_CNTR
This table also seems un ip-like, the usual format is a list of words,
I think.
It is true for key<->value data, but it is less obvious for bit
parsing.
Several of the word decodes are from bit fields..
Internally, I tried to present them as list and it was ugly like hell
without any chance (without extra parsing) to actual see if specific
capability is present or no.
lspci seems to have no problem being readable while doing this..

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help