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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200904133753.77ce6bc7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 4 Sep 2020 13:37:53 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sunil Kovvuri Goutham <sgoutham@...vell.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "sundeep.lkml@...il.com" <sundeep.lkml@...il.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 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).