On 10/1/19 3:47 PM, Kurt Van Dijck wrote: > 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. :D That's considered a HACK :) >>> 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 The flexcan and the ti_hecc drivers are converted to rx-offload. If your hardware has mailboxes with timestamps make use can_rx_offload_add_timestamp(): https://elixir.bootlin.com/linux/latest/source/drivers/net/can/flexcan.c#L1281 If your hardware offers the CAN frames in proper order use can_rx_offload_add_fifo(): https://elixir.bootlin.com/linux/latest/source/drivers/net/can/flexcan.c#L1285 Drop me a note, if you need more hints. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachment:
signature.asc
Description: OpenPGP digital signature
