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?