netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH v2] net: dsa: qca8k: pack driver struct and improve cache use
Date: Mon, 21 Mar 2022 20:22:26 +0200	[thread overview]
Message-ID: <20220321182226.zx2fqlntaxd7snup@skbuf> (raw)
In-Reply-To: <Yji2b6XF13E1o2x3@Ansuel-xps.localdomain>

On Mon, Mar 21, 2022 at 06:31:27PM +0100, Ansuel Smith wrote:
> On Mon, Mar 21, 2022 at 06:26:24PM +0100, Ansuel Smith wrote:
> > On Mon, Mar 21, 2022 at 07:22:00PM +0200, Vladimir Oltean wrote:
> > > On Mon, Mar 21, 2022 at 05:07:55PM +0100, Ansuel Smith wrote:
> > > > On Thu, Mar 03, 2022 at 03:53:27AM +0200, Vladimir Oltean wrote:
> > > > > On Mon, Feb 28, 2022 at 12:04:08PM +0100, Ansuel Smith wrote:
> > > > > > Pack qca8k priv and other struct using pahole and set the first priv
> > > > > > struct entry to mgmt_master and mgmt_eth_data to speedup access.
> > > > > > While at it also rework pcs struct and move it qca8k_ports_config
> > > > > > following other configuration set for the cpu ports.
> > > > > > 
> > > > > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > > > > > ---
> > > > > 
> > > > > How did you "pack" struct qca8k_priv exactly?
> > > > >
> > > > 
> > > > I'm trying to understand it too... also this was done basend on what
> > > > target? 
> > > 
> > > I used an arm64 toolchain, if that's what you're asking.
> > >
> > 
> > That could be the reason of different results. Qca8k is mostly used on
> > 32bit systems with 4byte cache wonder. That could be the reason i have
> > different results and on a system like that it did suggest this order?

Is it impossible to use the qca8k driver on 64-bit systems?

> > > > > Before:
> > > > > 
> > > > > struct qca8k_priv {
> > > > >         u8                         switch_id;            /*     0     1 */
> > > > >         u8                         switch_revision;      /*     1     1 */
> > > > >         u8                         mirror_rx;            /*     2     1 */
> > > > >         u8                         mirror_tx;            /*     3     1 */
> > > > >         u8                         lag_hash_mode;        /*     4     1 */
> > > > >         bool                       legacy_phy_port_mapping; /*     5     1 */
> > > > >         struct qca8k_ports_config  ports_config;         /*     6     7 */
> > > > > 
> > > > >         /* XXX 3 bytes hole, try to pack */
> > > > > 
> > > > >         struct regmap *            regmap;               /*    16     8 */
> > > > >         struct mii_bus *           bus;                  /*    24     8 */
> > > > >         struct ar8xxx_port_status  port_sts[7];          /*    32    28 */
> > > > > 
> > > > >         /* XXX 4 bytes hole, try to pack */
> > > > > 
> > > > >         /* --- cacheline 1 boundary (64 bytes) --- */
> > > > >         struct dsa_switch *        ds;                   /*    64     8 */
> > > > >         struct mutex               reg_mutex;            /*    72   160 */
> > > > >         /* --- cacheline 3 boundary (192 bytes) was 40 bytes ago --- */
> > > > >         struct device *            dev;                  /*   232     8 */
> > > > >         struct dsa_switch_ops      ops;                  /*   240   864 */
> > > > >         /* --- cacheline 17 boundary (1088 bytes) was 16 bytes ago --- */
> > > > >         struct gpio_desc *         reset_gpio;           /*  1104     8 */
> > > > >         unsigned int               port_mtu[7];          /*  1112    28 */
> > > > > 
> > > > >         /* XXX 4 bytes hole, try to pack */
> > > > > 
> > > > >         struct net_device *        mgmt_master;          /*  1144     8 */
> > > > >         /* --- cacheline 18 boundary (1152 bytes) --- */
> > > > >         struct qca8k_mgmt_eth_data mgmt_eth_data;        /*  1152   280 */
> > > > >         /* --- cacheline 22 boundary (1408 bytes) was 24 bytes ago --- */
> > > > >         struct qca8k_mib_eth_data  mib_eth_data;         /*  1432   272 */
> > > > >         /* --- cacheline 26 boundary (1664 bytes) was 40 bytes ago --- */
> > > > >         struct qca8k_mdio_cache    mdio_cache;           /*  1704     6 */
> > > > > 
> > > > >         /* XXX 2 bytes hole, try to pack */
> > > > > 
> > > > >         struct qca8k_pcs           pcs_port_0;           /*  1712    32 */
> > > > > 
> > > > >         /* XXX last struct has 4 bytes of padding */
> > > > > 
> > > > >         /* --- cacheline 27 boundary (1728 bytes) was 16 bytes ago --- */
> > > > >         struct qca8k_pcs           pcs_port_6;           /*  1744    32 */
> > > > > 
> > > > >         /* XXX last struct has 4 bytes of padding */
> > > > > 
> > > > >         /* size: 1776, cachelines: 28, members: 22 */
> > > > >         /* sum members: 1763, holes: 4, sum holes: 13 */
> > > > >         /* paddings: 2, sum paddings: 8 */
> > > > >         /* last cacheline: 48 bytes */
> > > > > };
> > > > > 
> > > > > After:
> > > > > 
> > > > > struct qca8k_priv {
> > > > >         struct net_device *        mgmt_master;          /*     0     8 */
> > > > >         struct qca8k_mgmt_eth_data mgmt_eth_data;        /*     8   280 */
> > > > >         /* --- cacheline 4 boundary (256 bytes) was 32 bytes ago --- */
> > > > >         struct qca8k_mdio_cache    mdio_cache;           /*   288     6 */
> > > > >         u8                         switch_id;            /*   294     1 */
> > > > >         u8                         switch_revision;      /*   295     1 */
> > > > >         u8                         mirror_rx;            /*   296     1 */
> > > > >         u8                         mirror_tx;            /*   297     1 */
> > > > >         u8                         lag_hash_mode;        /*   298     1 */
> > > > >         bool                       legacy_phy_port_mapping; /*   299     1 */
> > > > > 
> > > > >         /* XXX 4 bytes hole, try to pack */
> > > > > 
> > > > >         struct qca8k_ports_config  ports_config;         /*   304    72 */
> > > > >         /* --- cacheline 5 boundary (320 bytes) was 56 bytes ago --- */
> > > > >         struct regmap *            regmap;               /*   376     8 */
> > > > >         /* --- cacheline 6 boundary (384 bytes) --- */
> > > > >         struct mii_bus *           bus;                  /*   384     8 */
> > > > >         struct ar8xxx_port_status  port_sts[7];          /*   392    28 */
> > > > > 
> > > > >         /* XXX 4 bytes hole, try to pack */
> > > > > 
> > > > >         struct dsa_switch *        ds;                   /*   424     8 */
> > > > >         struct mutex               reg_mutex;            /*   432   160 */
> > > > >         /* --- cacheline 9 boundary (576 bytes) was 16 bytes ago --- */
> > > > >         struct device *            dev;                  /*   592     8 */
> > > > >         struct gpio_desc *         reset_gpio;           /*   600     8 */
> > > > >         struct dsa_switch_ops      ops;                  /*   608   864 */
> > > > >         /* --- cacheline 23 boundary (1472 bytes) --- */
> > > > >         struct qca8k_mib_eth_data  mib_eth_data;         /*  1472   280 */
> > > > > 
> > > > >         /* XXX last struct has 4 bytes of padding */
> > > > > 
> > > > >         /* --- cacheline 27 boundary (1728 bytes) was 24 bytes ago --- */
> > > > >         unsigned int               port_mtu[7];          /*  1752    28 */
> > > > > 
> > > > >         /* size: 1784, cachelines: 28, members: 20 */
> > > > >         /* sum members: 1772, holes: 2, sum holes: 8 */
> > > > >         /* padding: 4 */
> > > > >         /* paddings: 1, sum paddings: 4 */
> > > > >         /* last cacheline: 56 bytes */
> > > > > };
> > > > > 
> > > > > 1776 vs 1784. That's... larger?!
> > > > > 
> > > > > Also, struct qca8k_priv is so large because the "ops" member is a full
> > > > > copy of qca8k_switch_ops. I understand why commit db460c54b67f ("net:
> > > > > dsa: qca8k: extend slave-bus implementations") did this, but I wonder,
> > > > > is there no better way?
> > > > > 
> > > > 
> > > > Actually from what I can see the struct can be improved in 2 way...
> > > > The ancient struct
> > > > ar8xxx_port_status port_sts[QCA8K_NUM_PORTS];
> > > > can be totally dropped as I can't see why we still need it.
> > > > 
> > > > The duplicated ops is funny. I could be very confused but why it's done
> > > > like that? Can't we modify directly the already defined one and drop
> > > > struct dsa_switch_ops ops; from qca8k_priv?
> > > 
> > > Simply put, qca8k_switch_ops is per kernel, priv->ops is per driver
> > > instance.
> > > 
> > 
> > Right I totally missed that.
> > 
> > > > I mean is all of that to use priv->ops.phy_read instead of
> > > > priv->ds->ops.phy_read or even qca8k_switch_ops directly? o.o
> > > > 
> > > > Am I missing something?
> > > 
> > > The thing is that qca8k_setup_mdio_bus() wants DSA to use the
> > > legacy_phy_port_mapping only as a fallback. DSA uses this simplistic
> > > condition:
> > > 
> > > dsa_switch_setup():
> > > 	if (!ds->slave_mii_bus && ds->ops->phy_read) {
> > > 		ds->slave_mii_bus = mdiobus_alloc();
> > > 
> > > You might be tempted to say: hey, qca8k_mdio_register() populates
> > > ds->slave_mii_bus to an MDIO bus allocated by itself. So you'd be able
> > > to prune the mdiobus_alloc() because the first part of the condition is
> > > false.
> > > 
> > > But dsa_switch_teardown() has:
> > > 
> > > 	if (ds->slave_mii_bus && ds->ops->phy_read) {
> > > 		mdiobus_unregister(ds->slave_mii_bus);
> > > 
> > > In other words, dsa_switch_teardown() has lost track of who allocated
> > > the MDIO bus - it assumes that the DSA core has. That will conflict with
> > > qca8k which uses devres, so it would result in double free.
> > > 
> > > So that's basically what the problem is. The qca8k driver needs to have
> > > a NULL ds->ops->phy_read if it doesn't use the legacy_phy_port_mapping,
> > > so it won't confuse the DSA core.
> > > 
> > > Please note that I'm not really too familiar with this part of the DSA
> > > core since I don't have any hardware that makes any use of ds->slave_mii_bus.
> > > 
> > 
> > Ok now I see the problem. Thx for the good explaination. I wonder...
> > Should I use the easy path and just drop phy_read/write? Qca8k already
> > allocate a dedicated mdio for the same task... Should I just add some
> > check and make the dedicated mdio register without the OF API when it's
> > in legacy mode?
> > 
> > I think that at times the idea of that patch was to try to use as much
> > as possible generic dsa ops but if that would result in having the big
> > ops duplicated for every switch that doesn't seems that optmizied.
> > 
> > An alternative would be adding an additional flag to dsa to control how
> > DSA should handle slave_mii_bus. But I assume a solution like that would
> > be directly NACK as it's just an hack for a driver to save some space.
> > 
> > Or now that I think about it generilize all of this and add some API to
> > DSA to register an mdiobus with an mdio node if provided. Or even
> > provide some way to make the driver decide what to do... Some type of
> > configuration? Is it overkill or other driver would benefit from this?
> > Do we have other driver that declare a custom mdiobus instead of using
> > phy_read/write?
> >
> 
> I just checked we have 4 driver that implement custom mdiobus using an
> of node and would benefit from this... Still don't know if it would be a
> good solution.

If you provide your own ds->slave_mii_bus there should be no reason to
need a ds->ops->phy_read, since your slave_mii_bus already has one.

Bottom line, phy_read is just there in case they it is helpful.
Whereas ds->slave_mii_bus is there if you want to have a non-OF based
phy_connect, with the implicit assumption that the phy_addr is equal to
the port, and it can't be in any other way.

So if ds->ops->phy_read / ds->ops->phy_write aren't useful, don't use them.
I suppose one of the drivers you saw with "custom mdiobus" was sja1105.
I have no interest whatsoever in converting that driver to use
ds->slave_mii_bus or ds->phy_read.

  reply	other threads:[~2022-03-21 18:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 11:04 [net-next PATCH v2] net: dsa: qca8k: pack driver struct and improve cache use Ansuel Smith
2022-03-03  1:53 ` Vladimir Oltean
2022-03-03  2:25   ` Andrew Lunn
2022-03-21 16:07   ` Ansuel Smith
2022-03-21 17:22     ` Vladimir Oltean
2022-03-21 17:26       ` Ansuel Smith
2022-03-21 17:31         ` Ansuel Smith
2022-03-21 18:22           ` Vladimir Oltean [this message]
2022-03-21 18:06             ` Ansuel Smith
2022-03-21 18:55               ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220321182226.zx2fqlntaxd7snup@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).