On Fri, 8 Nov 2013, Stanislav Meduna wrote: > On the same wire there is a non-rt traffic, usually sent by another > lower-prio thread. The queuing of the packets itself is not a problem - > this is basically a request-response protocol and there will never > be more than several packets before the higher-level one - but So you exactly know that the non-rt traffic is never going to queue enough traffic to disturb your high prio traffic? That might be true for your particular scenario, but definitely not true for the general case as I showed with a very trivial example. > a priority inversion where the first thread is stuck in the network > code because something preempted the low-prio one that is just queuing > a packet would be a big problem. Did you even take the time to read and understand what I wrote? It's not a priority inversion problem. It's a problem of not understanding the technology. The default queue of the network stack is a single fifo queue. So what are you expecting from a single queue? That it's magically allowing your high priority task to succeed? And just because you are too lazy or unable to understand the concepts of advanced networking you join the choir and shout "priority inversion"? I explained, that this is an expected and completely correct behaviour which has absolutely nothing to do with priority inversion. There are other ways to solve this without touching a single line of kernel code. The technology is all there, you just have to use it. Of course that requires to understand it in the first place, though this seems to be way harder than spending a lot of time tracing the problem and then yelling "priority inversion" and hope that the RT folks are going to "fix" it. Hell no, there is no way to cure blissful ignorance with kernel patches. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
