On di, 01 okt 2019 11:40:09 +0200, Marc Kleine-Budde wrote: > On 9/30/19 9:30 PM, Kurt Van Dijck wrote: > > The napi-handler defers c_can reception to softirq, but it is hard to > > control the RT priority of the CAN recv end inside a softirq. > > Using an irqthread allows precise control of it's RT priority. > > Having the quota still around in the IRQ thread allows to restrict > > the work_done per cycle. > > > > Signed-off-by: Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> > > NACK, not pushing CAN frames though NAPI results in very strange things, > such like package reordering. This becomes interesting. Would you mind elaborating a bit on that. I'm currently trying to avoid CAN overflows on an RT system, where I eleveated the can irq thread above the others. Then I discovered that the softirqd waits a lot before being scheduled, but this one deal with all others too, so I started to question the whole softirq thing because its a garbage can for all postponed work. Mirgrating to a threaded irq seems wise to me then. If a single thread reads all the incoming messages from the chip, the are received in order, I assume. Who would reorder the packets? Is synchronizing rx/tx paths handled in napi? they depend on different softirqs, if I remember well. Kind regards, Kurt
