Messages in this thread | | | Date | Tue, 18 Apr 2023 15:59:57 -0500 | Subject | Re: [RFC PATCH 5/5] can: m_can: Add hrtimer to generate software interrupt | From | "Mendez, Judith" <> |
| |
Hello Marc,
On 4/17/2023 2:26 PM, Marc Kleine-Budde wrote: > On 17.04.2023 19:34:03, Oliver Hartkopp wrote: >> On 17.04.23 09:26, Marc Kleine-Budde wrote: >>> On 16.04.2023 21:46:40, Oliver Hartkopp wrote: >>>>> I had the 5ms that are actually used in the code in mind. But this is a >>>>> good calculation. >>>> >>>> @Judith: Can you acknowledge the value calculation? >>>> >>>>>> The "shortest" 11 bit CAN ID CAN frame is a Classical CAN frame with DLC = 0 >>>>>> and 1 Mbit/s (arbitration) bitrate. This should be 48 bits @1Mbit => ~50 >>>>>> usecs >>>>>> >>>>>> So it should be something about >>>>>> >>>>>> 50 usecs * (FIFO queue len - 2) >>>>> >>>>> Where does the "2" come from? >>>> >>>> I thought about handling the FIFO earlier than it gets completely "full". >>>> >>>> The fetching routine would need some time too and the hrtimer could also >>>> jitter to some extend. >>> >>> I was assuming something like this. >>> >>> I would argue that the polling time should be: >>> >>> 50 µs * FIFO length - IRQ overhead. >>> >>> The max IRQ overhead depends on your SoC and kernel configuration. >> >> I just tried an educated guess to prevent the FIFO to be filled up >> completely. How can you estimate the "IRQ overhead"? And how do you catch >> the CAN frames that are received while the IRQ is handled? > > We're talking about polling, better call it "overhead" or "latency from > timer expiration until FIFO has at least one frame room". This value > depends on your system. > > It depends on many, many factors, SoC, Kernel configuration (preempt RT, > powersaving, frequency scaling, system load. In your example it's 100 > µs. I wanted to say there's an overhead (or latency) and we need enough > space in the FIFO, to cover it. >
I am not sure how to estimate IRQ overhead, but FIFO length should be 64 elements.
50 us * 62 is about 3.1 ms and we are using 1 ms timer polling interval.
Running a few benchmarks showed that using 0.5 ms timer polling interval starts to take a toll on CPU load, that is why I chose 1 ms polling interval.
regards, Judith
| |