lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 21 Mar 2022 19:06:07 +0100
From:   Ansuel Smith <ansuelsmth@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH v2] net: dsa: qca8k: pack driver struct and
 improve cache use

On Mon, Mar 21, 2022 at 08:22:26PM +0200, Vladimir Oltean wrote:
> 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@...il.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?
>

It's possible but reality is that 99% it will be used on 32bit system.
Wonder if we should optimize for that.

> > > > > > 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.

My idea was to provide some type of API where the switch insert some
type of data and DSA decide to declare a dsa mdiobus or a
dedicated one based on the config provided. Think I will have to provide
an RFC to better describe this idea. The idea would be to drop phy_read
and phy_write and replace them with a single op that provide a
configuration.

-- 
	Ansuel

Powered by blists - more mailing lists