Interrupt duration and WiFi

[ille111]

I am doing some tests to measure the maximum timing impact on my real-time application through wifi-packets. For this I wrote a monitoring task that regularly prints out the lateness of my task (that is the time it takes longer than it should to run). When I prioritize my observed task lower than the wifi driver task, I of course see a significant increase in its lateness. I presume it is called for every incoming packet. The impact is even higher when it has a lower priority than the tcp/ip task. Also understandable.

Getting to my question: When my observed task has a higher priority than any other task I expect that only the NIC-triggered ISRs preempt this task. Yet, even under very high network loads I don't see any changes in the duration the task takes. I know that ISRs are very short and shouldn't take up too many cycles in any case, so I implemented my own one-liner ISR that adds an item to a FreeRTOS queue and returns. When I trigger this ISR via a GPIO pin in a similar frequency as a high packet load and under the same conditions, the impact is clearly visible.
How can that be? Are NIC interrupts somehow disabled when the driver cannot be immediately called or some buffer is full? It was necessary to use the highest available priority for the task for it not being preempted by the driver task. could this have an effect?

Thank you for any clarification!

[ESP_Sprite]

Perhaps your task/interrupt runs on a different core than the WiFi ISR? As the ESP32 is a 2-core CPU, this can happen.

[ille111]

That is not the case, I get the same result wehen running everything on the same core.

[ille111]

Does anyone have an idea? Without insight into the NIC and its driver it is very hard to find an answer to this question. Is there any possibility of checking weather the expected number of interrupts even occurs?