Re: [PATCH net-next v2 06/10] net: stmmac: Do not disable interrupts when cleaning TX
On Mon, Jul 1, 2019 at 6:15 AM Jose Abreu wrote: > > From: Willem de Bruijn > > > By the > > > > if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { > > stmmac_disable_dma_irq(priv, priv->ioaddr, chan); > > napi_schedule_irqoff(>rx_napi); > > } > > > > branch directly above? If so, is it possible to have fewer rx than tx > > queues and miss this? > > Yes, it is possible. And that is not a problem? > > > this logic seems more complex than needed? > > > > if (status) > > status |= handle_rx | handle_tx; > > > > if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { > > > > } > > > > if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) { > > > > } > > > > status & handle_rx implies status & handle_tx and vice versa. > > This is removed in patch 09/10. > > > > - if (work_done < budget && napi_complete_done(napi, work_done)) > > > - stmmac_enable_dma_irq(priv, priv->ioaddr, chan); > > > + if (work_done < budget) > > > + napi_complete_done(napi, work_done); > > > > It does seem odd that stmmac_napi_poll_rx and stmmac_napi_poll_tx both > > call stmmac_enable_dma_irq(..) independent of the other. Shouldn't the > > IRQ remain masked while either is active or scheduled? That is almost > > what this patch does, though not exactly. > > After patch 09/10 the interrupts will only be disabled by RX NAPI and > re-enabled by it again. I can do some tests on whether disabling > interrupts independently gives more performance but I wouldn't expect so > because the real bottleneck when I do iperf3 tests is the RX path ... Sharing the IRQ sounds fine. My only concern was TX-only IRQs in case more TX than RX queues are configured. If that is possible with this driver.
RE: [PATCH net-next v2 06/10] net: stmmac: Do not disable interrupts when cleaning TX
From: Willem de Bruijn > By the > > if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { > stmmac_disable_dma_irq(priv, priv->ioaddr, chan); > napi_schedule_irqoff(>rx_napi); > } > > branch directly above? If so, is it possible to have fewer rx than tx > queues and miss this? Yes, it is possible. > this logic seems more complex than needed? > > if (status) > status |= handle_rx | handle_tx; > > if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { > > } > > if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) { > > } > > status & handle_rx implies status & handle_tx and vice versa. This is removed in patch 09/10. > > - if (work_done < budget && napi_complete_done(napi, work_done)) > > - stmmac_enable_dma_irq(priv, priv->ioaddr, chan); > > + if (work_done < budget) > > + napi_complete_done(napi, work_done); > > It does seem odd that stmmac_napi_poll_rx and stmmac_napi_poll_tx both > call stmmac_enable_dma_irq(..) independent of the other. Shouldn't the > IRQ remain masked while either is active or scheduled? That is almost > what this patch does, though not exactly. After patch 09/10 the interrupts will only be disabled by RX NAPI and re-enabled by it again. I can do some tests on whether disabling interrupts independently gives more performance but I wouldn't expect so because the real bottleneck when I do iperf3 tests is the RX path ...
Re: [PATCH net-next v2 06/10] net: stmmac: Do not disable interrupts when cleaning TX
On Fri, Jun 28, 2019 at 3:30 AM Jose Abreu wrote: > > This is a performance killer and anyways the interrupts are being > disabled by RX NAPI so no need to disable them again. By the if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { stmmac_disable_dma_irq(priv, priv->ioaddr, chan); napi_schedule_irqoff(>rx_napi); } branch directly above? If so, is it possible to have fewer rx than tx queues and miss this? this logic seems more complex than needed? if (status) status |= handle_rx | handle_tx; if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) { } if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) { } status & handle_rx implies status & handle_tx and vice versa. > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: David S. Miller > Cc: Giuseppe Cavallaro > Cc: Alexandre Torgue > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index 4a5941caaadc..e8f3e76889c8 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -2061,10 +2061,8 @@ static int stmmac_napi_check(struct stmmac_priv *priv, > u32 chan) > napi_schedule_irqoff(>rx_napi); > } > > - if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) { > - stmmac_disable_dma_irq(priv, priv->ioaddr, chan); > + if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) > napi_schedule_irqoff(>tx_napi); > - } > > return status; > } > @@ -3570,8 +3568,8 @@ static int stmmac_napi_poll_tx(struct napi_struct > *napi, int budget) > work_done = stmmac_tx_clean(priv, DMA_TX_SIZE, chan); > work_done = min(work_done, budget); > > - if (work_done < budget && napi_complete_done(napi, work_done)) > - stmmac_enable_dma_irq(priv, priv->ioaddr, chan); > + if (work_done < budget) > + napi_complete_done(napi, work_done); It does seem odd that stmmac_napi_poll_rx and stmmac_napi_poll_tx both call stmmac_enable_dma_irq(..) independent of the other. Shouldn't the IRQ remain masked while either is active or scheduled? That is almost what this patch does, though not exactly.