All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: olteanv@gmail.com
Cc: kuba@kernel.org, netdev@vger.kernel.org, claudiu.manoil@nxp.com,
	ioana.ciornei@nxp.com, Jiafei.Pan@nxp.com, yangbo.lu@nxp.com,
	linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] enetc: use napi_schedule to be compatible with PREEMPT_RT
Date: Mon, 03 Aug 2020 18:21:45 -0700 (PDT)	[thread overview]
Message-ID: <20200803.182145.2300252460016431673.davem@davemloft.net> (raw)
In-Reply-To: <20200803201009.613147-2-olteanv@gmail.com>

From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon,  3 Aug 2020 23:10:09 +0300

> From: Jiafei Pan <Jiafei.Pan@nxp.com>
> 
> The driver calls napi_schedule_irqoff() from a context where, in RT,
> hardirqs are not disabled, since the IRQ handler is force-threaded.
> 
> In the call path of this function, __raise_softirq_irqoff() is modifying
> its per-CPU mask of pending softirqs that must be processed, using
> or_softirq_pending(). The or_softirq_pending() function is not atomic,
> but since interrupts are supposed to be disabled, nobody should be
> preempting it, and the operation should be safe.
> 
> Nonetheless, when running with hardirqs on, as in the PREEMPT_RT case,
> it isn't safe, and the pending softirqs mask can get corrupted,
> resulting in softirqs being lost and never processed.
> 
> To have common code that works with PREEMPT_RT and with mainline Linux,
> we can use plain napi_schedule() instead. The difference is that
> napi_schedule() (via __napi_schedule) also calls local_irq_save, which
> disables hardirqs if they aren't already. But, since they already are
> disabled in non-RT, this means that in practice we don't see any
> measurable difference in throughput or latency with this patch.
> 
> Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Applied.

  reply	other threads:[~2020-08-04  1:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 20:10 [PATCH net-next 1/2] dpaa2-eth: use napi_schedule to be compatible with PREEMPT_RT Vladimir Oltean
2020-08-03 20:10 ` [PATCH net-next 2/2] enetc: " Vladimir Oltean
2020-08-04  1:21   ` David Miller [this message]
2020-08-12 13:51     ` Sebastian Andrzej Siewior
2020-08-12 14:34       ` Vladimir Oltean
2020-08-12 15:13         ` Sebastian Andrzej Siewior
2020-08-24 10:59         ` Vladimir Oltean
2020-08-04  1:21 ` [PATCH net-next 1/2] dpaa2-eth: " David Miller

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=20200803.182145.2300252460016431673.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=Jiafei.Pan@nxp.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=yangbo.lu@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.