Thread (12 messages) flat view 12 messages, 5 authors, 2021-05-21

Re: [PATCH net-next 1/2] net: add a napi variant for RT-well-behaved drivers

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-05-15 20:38:49

On Sat, 15 May 2021 11:49:02 +0200 Thomas Gleixner wrote:
On Fri, May 14 2021 at 15:24, Jakub Kicinski wrote:
quoted
 /**
- *	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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help