Re: [PATCH net-next v14 5/7] net: dsa: mv88e6xxx: rmu: Add functionality to get RMON

On 2022-09-20 23:04, Andrew Lunn wrote:

On Tue, Sep 20, 2022 at 04:10:53PM +0300, Vladimir Oltean wrote:

quoted

On Tue, Sep 20, 2022 at 02:26:22PM +0200, Mattias Forsblad wrote:

quoted

This whole shebang was a suggestion from Andrew. I had a solution with
mv88e6xxx_rmu_available in mv88e6xxx_get_ethtool_stats which he wasn't fond of.
The mv88e6xxx_bus_ops is declared const and how am I to change the get_rmon
member? I'm not really sure on how to solve this in a better way?
Suggestions any? Maybe I've misunderstood his suggestion.

Can you point me to the beginning of that exact suggestion? I've removed
everything older than v10 from my inbox, since the flow of patches was
preventing me from seeing other emails.

What i want to do is avoid code like:

     if (have_rmu())
     	foo()
     else
	bar()

There is nothing common in the MDIO MIB code and the RMU MIB code,
just the table of statistics. When we get to dumping the ATU, i also
expect there will be little in common between the MDIO and the RMU
functions.

Doing MIB via RMU is a big gain, but i would also like normal register
read and write to go via RMU, probably with some level of
combining. Multiple writes can be combined into one RMU operation
ending with a read. That should give us an mv88e6xxx_bus_ops which
does RMU, and we can swap the bootstrap MDIO bus_ops for the RMU
bus_ops.

But how do we mix RMU MIB and ATU dumps into this? My idea was to make
them additional members of mv88e6xxx_bus_ops. The MDIO bus_ops
structures would end up call the mv88e6xxx_ops method for MIB or
ATU. The rmu bus_ops and directly call an RMU function to do it.

What is messy at the moment is that we don't have register read/write
via RMU, so we have some horrible hybrid. We should probably just
implement simple read and write, without combining, so we can skip
this hybrid.

I am assuming here that RMU is reliable. The QCA8K driver currently
falls back to MDIO if its inband function is attempted but fails.  I
want to stress this part, lots of data packets and see if the RMU
frames get dropped, or delayed too much causing failures. If we do see
failures, is a couple of retires enough? Or do we need to fallback to
MDIO which should always work? If we do need to fallback, this
structure is not going to work too well.

	  Andrew

I understand want you want but I can see a lot of risks and pitfalls with moving
ordinary read and writes to RMU, which I wanted to avoid by first doing
RMON dump and then dump ATU and at a later stage with a better architecture
for write/read combining doing that, instead of forcing through read/writes
with all associated testing it would require. Can we please do this in
steps?

/Mattias