Mon, Sep 07, 2020 at 12:59:45PM CEST, sundeep.l...@gmail.com wrote: >Hi Jakub, > >On Sat, Sep 5, 2020 at 2:07 AM Jakub Kicinski <k...@kernel.org> wrote: >> >> On Fri, 4 Sep 2020 12:29:04 +0000 Sunil Kovvuri Goutham wrote: >> > > >No, there are 3 drivers registering to 3 PCI device IDs and there can >> > > >be many instances of the same devices. So there can be 10's of >> > > >instances of >> > > AF, PF and VFs. >> > > >> > > So you can still have per-pci device devlink instance and use the >> > > tracepoint >> > > Jakub suggested. >> > > >> > >> > Two things >> > - As I mentioned above, there is a Crypto driver which uses the same mbox >> > APIs >> > which is in the process of upstreaming. There also we would need trace >> > points. >> > Not sure registering to devlink just for the sake of tracepoint is >> > proper. >> > >> > - The devlink trace message is like this >> > >> > TRACE_EVENT(devlink_hwmsg, >> > . . . >> > TP_printk("bus_name=%s dev_name=%s driver_name=%s incoming=%d >> > type=%lu buf=0x[%*phD] len=%zu", >> > __get_str(bus_name), __get_str(dev_name), >> > __get_str(driver_name), __entry->incoming, __entry->type, >> > (int) __entry->len, __get_dynamic_array(buf), >> > __entry->len) >> > ); >> > >> > Whatever debug message we want as output doesn't fit into this. >> >> Make use of the standard devlink tracepoint wherever applicable, and you >> can keep your extra ones if you want (as long as Jiri don't object). > >Sure and noted. I have tried to use devlink tracepoints and since it >could not fit our purpose I used these.
Why exactly the existing TP didn't fit your need? > >Thanks, >Sundeep