Messages in this thread | | | Date | Mon, 17 Apr 2023 14:55:57 +0200 | From | Simon Horman <> | Subject | Re: [PATCH net-next 3/7] net: mscc: ocelot: optimize ocelot_mm_irq() |
| |
On Sat, Apr 15, 2023 at 08:05:47PM +0300, Vladimir Oltean wrote: > The MAC Merge IRQ of all ports is shared with the PTP TX timestamp IRQ > of all ports, which means that currently, when a PTP TX timestamp is > generated, felix_irq_handler() also polls for the MAC Merge layer status > of all ports, looking for changes. This makes the kernel do more work, > and under certain circumstances may make ptp4l require a > tx_timestamp_timeout argument higher than before. > > Changes to the MAC Merge layer status are only to be expected under > certain conditions - its TX direction needs to be enabled - so we can > check early if that is the case, and omit register access otherwise. > > Make ocelot_mm_update_port_status() skip register access if > mm->tx_enabled is unset, and also call it once more, outside IRQ > context, from ocelot_port_set_mm(), when mm->tx_enabled transitions from > true to false, because an IRQ is also expected in that case. > > Also, a port may have its MAC Merge layer enabled but it may not have > generated the interrupt. In that case, there's no point in writing to > DEV_MM_STATUS to acknowledge that IRQ. We can reduce the number of > register writes per port with MM enabled by keeping an "ack" variable > which writes the "write-one-to-clear" bits. Those are 3 in number: > PRMPT_ACTIVE_STICKY, UNEXP_RX_PFRM_STICKY and UNEXP_TX_PFRM_STICKY. > The other fields in DEV_MM_STATUS are read-only and it doesn't matter > what is written to them, so writing zero is just fine. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
No need to respin on my account. However, I do observe that this patch is doing several things, and I do wonder if it could have been more than one patch.
| |