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 > > Jason > -- > 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
Attachment:
signature.asc
Description: PGP signature
