On 5/1/2018 3:09 AM, Leon Romanovsky wrote: > On Mon, Apr 30, 2018 at 05:02:09PM -0600, Jason Gunthorpe wrote: >> On Mon, Apr 30, 2018 at 05:52:49PM +0300, Leon Romanovsky wrote: >>> On Mon, Apr 30, 2018 at 08:45:10AM -0600, Jason Gunthorpe wrote: >>>> On Mon, Apr 23, 2018 at 04:19:00PM +0300, Leon Romanovsky wrote: >>>>>>>> If you send that integer when the RDMA_NLDEV_ATTR_PROVIDER is opened >>>>>>>> then the userspace at least knows what driver sent the data.. >>>>>>>> >>>>>>> The provider-specific data comes along with the core resource attributes for >>>>>>> a given resource query. It isn't like an application can query just >>>>>>> provider attributes. It queries a resource or set of them or all of them, >>>>>>> and it gets back core+provide attrs for each resource. >>>>>> It is not about the query, it is about having the data be >>>>>> self-describing.. There is no easy way to guess what the underlying >>>>>> device is to interpret the strings. >>>>> Not really, in order to get data from the kernel, user will send query >>>>> with specific ib_device index and this index will be returned back. >>>> The rdma device index doesn't tell you what driver is behind this >>>> without a lot of complicated work. The driver id is intended for this >>>> purpose. >>> I don't see why rdmatool user should care about which driver is connected >>> to specific ib_device. >> rdmatool shouldn't, but if Steve makes a custom tool only for cxgb4 >> then it should be able to know that it is getting counter data from >> the right driver and not some other random place. > I think that "-p" option of rdmatool gives to Steve needed flexibility > to provide aesthetic display, while preserving scriptability. > > Thanks > After implementing "-p" and also considering that without "-p" all the data is on one single row, any tool I implement, if I really need/want one, would probably be with grep/awk/etc... Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
