[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201031101215.38a13e51@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Sat, 31 Oct 2020 10:12:15 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: netdev@...r.kernel.org, Aymen Sghaier <aymen.sghaier@....com>,
Daniel Drake <dsd@...too.org>,
"David S. Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
Horia Geantă <horia.geanta@....com>,
Jon Mason <jdmason@...zu.us>, Jouni Malinen <j@...fi>,
Kalle Valo <kvalo@...eaurora.org>,
Leon Romanovsky <leon@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-rdma@...r.kernel.org,
linux-wireless@...r.kernel.org, Li Yang <leoyang.li@....com>,
Madalin Bucur <madalin.bucur@....com>,
Ping-Ke Shih <pkshih@...ltek.com>,
Rain River <rain.1986.08.12@...il.com>,
Saeed Mahameed <saeedm@...dia.com>,
Samuel Chessman <chessman@....org>,
Ulrich Kunitz <kune@...ne-taler.de>,
Zhu Yanjun <zyjzyj2000@...il.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH net-next 14/15] net: dpaa: Replace in_irq() usage.
On Tue, 27 Oct 2020 23:54:53 +0100 Sebastian Andrzej Siewior wrote:
> The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI
> scheduling is required or packet processing.
>
> The usage of in_*() in drivers is phased out and Linus clearly requested
> that code which changes behaviour depending on context should either be
> seperated or the context be conveyed in an argument passed by the caller,
> which usually knows the context.
>
> Use the `napi' argument passed by the callback. It is set true if
> called from the interrupt handler and NAPI should be scheduled.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Cc: "Horia Geantă" <horia.geanta@....com>
> Cc: Aymen Sghaier <aymen.sghaier@....com>
> Cc: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: "David S. Miller" <davem@...emloft.net>
> Cc: Madalin Bucur <madalin.bucur@....com>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Li Yang <leoyang.li@....com>
> Cc: linux-crypto@...r.kernel.org
> Cc: netdev@...r.kernel.org
> Cc: linuxppc-dev@...ts.ozlabs.org
> Cc: linux-arm-kernel@...ts.infradead.org
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 27835310b718e..2c949acd74c67 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2300,9 +2300,9 @@ static void dpaa_tx_conf(struct net_device *net_dev,
> }
>
> static inline int dpaa_eth_napi_schedule(struct dpaa_percpu_priv *percpu_priv,
> - struct qman_portal *portal)
> + struct qman_portal *portal, bool napi)
> {
> - if (unlikely(in_irq() || !in_serving_softirq())) {
> + if (napi) {
> /* Disable QMan IRQ and invoke NAPI */
> qman_p_irqsource_remove(portal, QM_PIRQ_DQRI);
>
Nit: some networking drivers have a bool napi which means "are we
running in napi context", the semantics here feel a little backwards,
at least to me. But if I'm the only one thinking this, so be it.
Powered by blists - more mailing lists