On Mon, Jun 26, 2017 at 02:36:10PM -0600, Jason Gunthorpe wrote: > 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: > > > 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 values 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. > > > > > $ 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.. No problem, If i understand you correctly, you are suggesting to drop parsing of "caps" as a separate command and embed it into general show <devname>. Can you help me and give an example of how would you present those caps? What will be the output of such command? $ rdma dev show mlx5_4 Thanks > > Jason
Attachment:
signature.asc
Description: PGP signature
