On Wed, Sep 16, 2020 at 4:04 PM Jiri Pirko <j...@resnulli.us> wrote:
>
> 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?
>
Existing TP has provision to dump skb and trace error strings with
error code but
we are trying to trace the entire mailbox flow of the AF/PF and VF
drivers. In particular
we trace the below:
message allocation with message id and size at initiator.
number of messages sent and total size.
check message requester id, response id and response code after
reply is received.
interrupts happened on behalf of mailboxes in the entire process
with source and receiver of interrupt along with isr status.
error like initiator timeout waiting for response.
All the above are relevant and are required for Octeontx2 only hence
used own tracepoints.
Thanks,
Sundeep
> >
> >Thanks,
> >Sundeep
