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: > > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > 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. > > > $ 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? > > > $ rdma dev show mlx5_4 cap_flags > > Unknown parameter 'caps_flags'. > > ? An example of "wrong" parameter. There is no such caps_flags. > > Jason
Attachment:
signature.asc
Description: PGP signature
