On di, 01 okt 2019 15:12:58 +0200, Marc Kleine-Budde wrote: > On 10/1/19 12:22 PM, Kurt Van Dijck wrote: > > 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. > > RT with PREEMPT_RT? yes. > > > 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. > > AFAIC you're only allowed to use netif_receive_skb() from softirq, i.e. > the NAPI context, see the documentation: > > https://elixir.bootlin.com/linux/latest/source/net/core/dev.c#L5265 > > I'm not sure about threated IRQ handlers....but from hard-IRQ context, > you should use netif_rx(): > > https://elixir.bootlin.com/linux/latest/source/net/core/dev.c#L4544 > > and netif_rx_ni() from threaded IRQ context: > > https://elixir.bootlin.com/linux/latest/source/net/core/dev.c#L4557 Thanks, I'll take a look at that. > > Please switch on all lockdep stuff and watch out for "softirq abc > pending" messages. I got rid of the local_softirq_pending() after I elevated softirqd to above the cpu-consuming RT threads. > > > 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. > > If, for the above reasons you have to use netif_rx(_ni)() and are on a > multicore system, the packets might be delivered on different CPUs and > processed in the wrong order. I have to google for more details... I see. I live in beaglebone singlecore world, but I don't want to break multicore operation either. > > What about reading the packet from the hardware in IRQ context and > putting them into the networking stack in NAPI. The rx-offload does > basically this. I'll look at this Thanks for the pointers
