On Fri, 14 May 2021 22:16:10 +0200 Thomas Gleixner wrote: > On Fri, May 14 2021 at 11:56, Jakub Kicinski wrote: > > On Thu, 13 May 2021 00:28:02 +0200 Thomas Gleixner wrote: > >> Blame me for that decision. > >> > >> No matter which variant we end up with, this needs to go into all stable > >> RT kernels ASAP. > > > > Mumble mumble. I thought we concluded that drivers used on RT can be > > fixed, we've already done it for a couple drivers (by which I mean two). > > If all the IRQ handler is doing is scheduling NAPI (which it is for > > modern NICs) - IRQF_NO_THREAD seems like the right option. > > Yes. That works, but there are a bunch which do more than that IIRC. > > > Is there any driver you care about that we can convert to using > > IRQF_NO_THREAD so we can have new drivers to "do the right thing" > > while the old ones depend on this workaround for now? > > The start of this thread was about i40e_msix_clean_rings() which > probably falls under the IRQF_NO_THREAD category, but I'm sure that > there are others. So I chose the safe way for RT for now. Sounds reasonable. I'll send a patch with a new helper and convert an example driver I'm sure falls into the "napi_schedule(); return;" category. I just want to make sure "the right thing to do" is accessible for people writing new drivers.
