netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	eric.dumazet@gmail.com, simon.horman@netronome.com,
	oss-drivers@netronome.com, bigeasy@linutronix.de
Subject: Re: [PATCH net-next 1/2] net: add a napi variant for RT-well-behaved drivers
Date: Sat, 15 May 2021 13:38:44 -0700	[thread overview]
Message-ID: <20210515133844.21f08a5e@kicinski-fedora-PC1C0HJN> (raw)
In-Reply-To: <87pmxs1g4x.ffs@nanos.tec.linutronix.de>

On Sat, 15 May 2021 11:49:02 +0200 Thomas Gleixner wrote:
> On Fri, May 14 2021 at 15:24, Jakub Kicinski wrote:
> >  /**
> > - *	napi_schedule_irqoff - schedule NAPI poll
> > - *	@n: NAPI context
> > + * napi_schedule_irq() - schedule NAPI poll from hardware IRQ
> > + * @n: NAPI context
> >   *
> >   * Variant of napi_schedule(), assuming hard irqs are masked.
> > + * Hardware interrupt handler must be marked with IRQF_NO_THREAD
> > + * to safely invoke this function on CONFIG_RT=y kernels (unless
> > + * it manually masks the interrupts already).
> >   */
> > -static inline void napi_schedule_irqoff(struct napi_struct *n)
> > +static inline void napi_schedule_irq(struct napi_struct *n)
> >  {
> >  	if (napi_schedule_prep(n))
> > -		__napi_schedule_irqoff(n);
> > +		__napi_schedule_irq(n);  
> 
> As this is intended for the trivial
> 
>    irqhandler()
>         napi_schedule_irq(n);
>         return IRQ_HANDLED;
> 
> case, wouldn't it make sense to bring napi_schedule_irq() out of line
> and have the prep invocation right there?
> 
> void napi_schedule_irq(struct napi_struct *n)
> {
>  	if (napi_schedule_prep(n))
> 		____napi_schedule(this_cpu_ptr(&softnet_data), n);
> }
> EXPORT_SYMBOL(napi_schedule_irq);
> 
> As that spares a function call and lets the compiler be smarter about
> it. I might be missing something though, but at least brain is more
> awake now :)

I'm just copying the existing two handlers (reviewer's favorite
response, I know) :)

My guess is .._prep() used to be a static inline itself, I can look 
at modifying all helpers if the assembly really looks better, but based
on Sebastian's email I'm not sure we're gonna go ahead with the new 
helper at all?

  reply	other threads:[~2021-05-15 20:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 22:24 [PATCH net-next 1/2] net: add a napi variant for RT-well-behaved drivers Jakub Kicinski
2021-05-14 22:24 ` [PATCH net-next 2/2] nfp: use napi_schedule_irq() Jakub Kicinski
2021-05-17  9:48   ` Simon Horman
2021-05-15  0:17 ` [PATCH net-next 1/2] net: add a napi variant for RT-well-behaved drivers Thomas Gleixner
2021-05-15  0:21   ` Jakub Kicinski
2021-05-15  0:29     ` Thomas Gleixner
2021-05-15  9:49 ` Thomas Gleixner
2021-05-15 20:38   ` Jakub Kicinski [this message]
2021-05-15 11:07 ` Sebastian Andrzej Siewior
2021-05-15 20:31   ` Jakub Kicinski
2021-05-15 20:53     ` Thomas Gleixner
2021-05-21 14:11       ` Juri Lelli

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=20210515133844.21f08a5e@kicinski-fedora-PC1C0HJN \
    --to=kuba@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=simon.horman@netronome.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).