> On Mon, May 14, 2018 at 05:04:26PM -0500, Steve Wise wrote: > > > > > > On 5/14/2018 3:41 PM, Jason Gunthorpe wrote: > > > On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote: > > >> This enhancement allows printing rdma device-specific state, if provided > > >> by the kernel. This is done in a generic manner, so rdma tool doesn't > > >> need to know about the details of every type of rdma device. > > >> > > >> Driver attributes for a rdma resource are in the form of <key, > > >> [print_type], value> tuples, where the key is a string and the value can > > >> be any supported driver attribute. The print_type attribute, if present, > > >> provides a print format to use vs the standard print format for the type. > > >> For example, the default print type for a PROVIDER_S32 value is "%d ", > > >> but "0x%x " if the print_type of PRINT_TYPE_HEX is included inthe tuple. > > >> > > >> Driver resources are only printed when the -dd flag is present. > > >> If -p is present, then the output is formatted to not exceed 80 columns, > > >> otherwise it is printed as a single row to be grep/awk friendly. > > >> > > >> Example output: > > >> > > >> # rdma resource show qp lqpn 1028 -dd -p > > >> link cxgb4_0/- lqpn 1028 rqpn 0 type RC state RTS rq-psn 0 sq-psn 0 > path-mig-state MIGRATED pid 0 comm [nvme_rdma] > > >> sqid 1028 flushed 0 memsize 123968 cidx 85 pidx 85 wq_pidx 106 > flush_cidx 85 in_use 0 > > >> size 386 flags 0x0 rqid 1029 memsize 16768 cidx 43 pidx 41 wq_pidx > 171 msn 44 rqt_hwaddr 0x2a8a5d00 > > >> rqt_size 256 in_use 128 size 130 idx 43 wr_id 0xffff881057c03408 idx > 40 wr_id 0xffff881057c033f0 > > > Hey some of these look like kernel pointers.. That is a no-no.. What > > > is up there? > > > > Nothing is defined as a kernel pointer. But wr_id is often a pointer to > > the kernel rdma application's context... > > > > > The wr_id often contains a pointer, right? So we cannot just pass it > > > to user space.. > > > > Hmm. It is useful for debugging kernel rdma applications. Perhaps > > these attrs can be only be sent up by the kernel if the capabilities > > allow. But previous review comments of the kernel series, which is now > > merged, forced me to remove passing the capabilities information to the > > driver resource fill functions. > > > > So what's the right way to do this? > > The reviewer asked do not pass to drivers whole CAP_.. bits, because > they anyway don't need such granularity. > Ok thanks. -- 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
