Re: [net-next RFC PATCH 3/4] net: dsa: qca8k: rework mib autocast handling

[Vladimir Oltean]

On Mon, Jul 18, 2022 at 07:20:07PM +0200, Christian Marangi wrote:
> On Mon, Jul 18, 2022 at 08:27:12PM +0300, Vladimir Oltean wrote:
> > On Sat, Jul 16, 2022 at 07:49:57PM +0200, Christian Marangi wrote:
> > > In preparation for code split, move the autocast mib function used to
> > > receive mib data from eth packet in priv struct and use that in
> > > get_ethtool_stats instead of referencing the function directly. This is
> > > needed as the get_ethtool_stats function will be moved to a common file.
> > > 
> > > Signed-off-by: Christian Marangi <ansuelsmth@xxxxxxxxx>
> > > ---
> > 
> > Can this change be deferred until there actually appears a second
> > implementation of (*autocast_mib)?
> >
> 
> Mhhh it would be problematic since I would like to move the ethtools
> stats function to common code and keep the autocast_mib handler in the
> qca8k specific code.
> 
> An alternative would be to keep the entire ethtool stats function in
> qca8k specific code but it needs to be moved anyway.
> 
> This change is required as probably ipq4019 mmio will be faster to
> access mib data than using the autocast way.
> 
> Tell me how to proceed. Think to skip this we have to leave ethtool
> stats function in qca8k specific code and move it later?

Sorry, I think I initially misread the patch. So ipq4019 is not going to
have an implementation of (*autocast_mib) at all? In that case I don't
have an objection to make it a function pointer now, but you need to
state exactly that in the commit message: make MIB autocast optional in
qca8k_get_ethtool_stats(), because we'll need to support an MMIO-based
switch in the future where we won't need to implement this function.

> > > diff --git a/drivers/net/dsa/qca/qca8k.h b/drivers/net/dsa/qca/qca8k.h
> > > index 22ece14e06dc..a306638a7100 100644
> > > --- a/drivers/net/dsa/qca/qca8k.h
> > > +++ b/drivers/net/dsa/qca/qca8k.h
> > > @@ -403,6 +403,7 @@ struct qca8k_priv {
> > >  	struct qca8k_mdio_cache mdio_cache;
> > >  	struct qca8k_pcs pcs_port_0;
> > >  	struct qca8k_pcs pcs_port_6;
> > > +	int (*autocast_mib)(struct dsa_switch *ds, int port, u64 *data);
> > 
> > Typically we hold function pointers in separate read-only structures rather
> > than in the stateful private structure of the driver, see struct sja1105_info,
> > struct felix_info, struct mv88e6xxx_info and mv88e6xxx_ops, struct b53_io_ops,
> > etc etc.
> > 
> 
> Oh ok it's just match data. We should already have something like that
> in qca8k but I wasn't aware of the _info suffix. If we decide to keep
> this, can i allign the match struct we use in qca8k to the new pattern
> and add the function pointer there?

I think struct qca8k_match_data could serve that purpose, and have a
sub-structure called qca8k_ops for function pointers, yes.