[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200622135510.GN338481@lunn.ch>
Date: Mon, 22 Jun 2020 15:55:10 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Kurt Kanzenbach <kurt@...utronix.de>
Cc: Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org
Subject: Re: [RFC PATCH 6/9] net: dsa: hellcreek: Add debugging mechanisms
On Mon, Jun 22, 2020 at 02:32:28PM +0200, Kurt Kanzenbach wrote:
> On Fri Jun 19 2020, Andrew Lunn wrote:
> >> > Are trace registers counters?
> >>
> >> No. The trace registers provide bits for error conditions and if packets
> >> have been dropped e.g. because of full queues or FCS errors, and so on.
> >
> > Is there some documentation somewhere? A better understanding of what
> > they can do might help figure out the correct API.
>
> No, not that I'm aware of.
>
> Actually there are a few more debugging mechanisms and features which
> should be exposed somehow. Here's the list:
>
> * Trace registers for the error conditions. This feature needs to be
> configured for which ports should be traced
> * Memory registers for indicating how many free page and meta pointers
> are available (read-only)
> * Limit registers for configuring:
> * Maximum memory limit per port
> * Reserved memory for critical traffic
> * Background traffic rate
> * Maximum queue depth
> * Re-prioritization of packets based on the ether type (not mac address)
> * Packet logging (-> retrieval of packet time stamps) based on port, traffic class and direction
> * Queue tracking
>
> What API would be useful for these mechanisms?
Hi Kurt
You should take a look at devlink. Many of these fit devlink
resources. Use that where it fits. But you might end up with an out of
tree debugfs patch for your own debugging work. We have something
similar of mv88e6xxx.
Andrew
Powered by blists - more mailing lists