[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230421213850.5ca0b347e99831e534b79fe7@kernel.org>
Date: Fri, 21 Apr 2023 21:38:50 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Andrew Lunn <andrew@...n.ch>, Steven Rostedt <rostedt@...dmis.org>,
netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next 0/2] DSA trace events
On Wed, 12 Apr 2023 12:55:34 +0300
Vladimir Oltean <vladimir.oltean@....com> wrote:
> On Wed, Apr 12, 2023 at 02:48:35AM +0200, Andrew Lunn wrote:
> > On Fri, Apr 07, 2023 at 05:14:49PM +0300, Vladimir Oltean wrote:
> > > This series introduces the "dsa" trace event class, with the following
> > > events:
> > >
> > > $ trace-cmd list | grep dsa
> > > dsa
> > > dsa:dsa_fdb_add_hw
> > > dsa:dsa_mdb_add_hw
> > > dsa:dsa_fdb_del_hw
> > > dsa:dsa_mdb_del_hw
> > > dsa:dsa_fdb_add_bump
> > > dsa:dsa_mdb_add_bump
> > > dsa:dsa_fdb_del_drop
> > > dsa:dsa_mdb_del_drop
> > > dsa:dsa_fdb_del_not_found
> > > dsa:dsa_mdb_del_not_found
> > > dsa:dsa_lag_fdb_add_hw
> > > dsa:dsa_lag_fdb_add_bump
> > > dsa:dsa_lag_fdb_del_hw
> > > dsa:dsa_lag_fdb_del_drop
> > > dsa:dsa_lag_fdb_del_not_found
> > > dsa:dsa_vlan_add_hw
> > > dsa:dsa_vlan_del_hw
> > > dsa:dsa_vlan_add_bump
> > > dsa:dsa_vlan_del_drop
> > > dsa:dsa_vlan_del_not_found
> > >
> > > These are useful to debug refcounting issues on CPU and DSA ports, where
> > > entries may remain lingering, or may be removed too soon, depending on
> > > bugs in higher layers of the network stack.
> >
> > Hi Vladimir
> >
> > I don't know anything about trace points. Should you Cc:
> >
> > Steven Rostedt <rostedt@...dmis.org> (maintainer:TRACING)
> > Masami Hiramatsu <mhiramat@...nel.org> (maintainer:TRACING)
> >
> > to get some feedback from people who do?
> >
> > Andrew
>
> I suppose I could.
>
> Hi Steven, Masami, would you mind taking a look and letting me know
> if the trace API was used reasonably? The patches were merged as:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=9538ebce88ffa074202d592d468521995cb1e714
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=02020bd70fa6abcb1c2a8525ce7c1500dd4f44a8
> but I can make incremental changes if necessary.
If the subsystem maintainers are OK for including this, it is OK.
But basically, since the event is exposed to userland and you may keep
these events maintained, you should carefully add the events.
If those are only for debugging (after debug, it will not be used
frequently), can you consider to use kprobe events?
'perf probe' command will also help you to trace local variables and
structure members as like gdb does.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists