Hi,

quoted

IMHO something in igb_watchdog_task causes the latency independently
from actual link. At first glance I would suspect igb_update_stats
(called with spinlock
held) as it seems to do a lot of reads. Maybe this stalls somehow.
Does the latency still occur if you comment that spinlock and call to
igb_update_stats out?

I tried that, however the result is the very same. I have the very same latency spikes
as before.
I went even further. Within the function igb_watchdog_task I removed everything but
the call to igb_has_link() and the final timer reset.
However even that led to the same result.
And there I am again at the findings in one of my previous postings within this
thread.
The call to igb_has_link might be a reason for the latency jitters, however I cannot
really break it down into a single piece of code that is relevant here.

I tried something completely different: 
I used the Intel Linux igb driver from the Intel website
(version 5.3.5.3) and tried this driver on the rt_preempt kernels 3.18.27-rt27 as well as
on the 4.6.7-rt13.
And also here I saw the same effect: With the 3.18.27 the cyclictest shows really great results
but with the 4.6.7 the cyclictest results show spikes once a igb based NIC is enabled.
For me this looks as if there is something running differently in the "underground" and the 
igb driver is make some strange effect visible.
Any ideas on this new finding?

Regards

Mathias