driver: disabling DOI during RX handling in NAPI: to do or not to do
As I'm describing this particular bit of implementation in the thesis, I intended to write why this behavior (i.e. disabling DOI for RX handling) is necessary, but realized I can not justify it enough.
Originally it was introduced because I thought it's the cause of #183 (closed), but that proved to be false (I just needed to clear DOR flag too). The argument that it is better to be reading the data than to handle DOI sounds weak to me - we're not on a slow high realtime cpu. Moreover, about the only place where the overrun could occur is between the RXBNEI and reading all the frames, and we would really want to be informed about the overrun. Plus some other process might take over the NAPI process, or the SW RX queue might become full, in which case the NAPI stays queued, but stopped.
It is now clear that the current approach is wrong. An alternative is to disable/reenable DOI in the polling routine. That does not sound too bad. The DOR flag would be checked after reading all the available frames, so that performance shouldn't be significantly hurt (one extra bus access).
There might be, however, a situation, when continuous data are streamed on CAN and DOR is used by the protocol to detect that a frame will be missing. Due to HW queuing, it can only be used to mean that "somewhere in the near future", a frame (or more) went missing, not "exactly after this frame" some went missing. IMHO this is an useless problem, as nobody sane would be leveraging this mechanism
On second reading, the "after reading all the frames, check for overrun" part sounds a bit ridiculous. It still might make sense when max work quota is reached, but would still be problematic if the thread is preempted (for a non-short time). That might not happen with current NAPI implementation, but who knows ...
So in conclusion: remove the special handling and keep it just in ISR, then test that it really works (it should)