netdev - Re: [EXT] Re: [net-next PATCH 0/2] Introduce mbox tracepoints for Octeontx2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Sep 2020 22:49:36 +0530
From:   sundeep subbaraya <sundeep.lkml@...il.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>
Subject: Re: [EXT] Re: [net-next PATCH 0/2] Introduce mbox tracepoints for Octeontx2

On Wed, Sep 16, 2020 at 4:04 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Mon, Sep 07, 2020 at 12:59:45PM CEST, sundeep.lkml@...il.com wrote:
> >Hi Jakub,
> >
> >On Sat, Sep 5, 2020 at 2:07 AM Jakub Kicinski <kuba@...nel.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