On 08.11.2013 03:07, Thomas Gleixner wrote:
> Simply because it has nothing to do with priority inversion. It's just
> the nature of a single unmanaged queue. The behaviour is completely
> correct.
I cannot comment on the code as I did not analyze it myself
(at least yet), but I think Nebojsa is worried by the situation
where the high-prio thread is not able to _queue_ its packets because
of the low-prio thread is sitting in some lock being preempted
by something unrelated.
> Just for the record. I'm really frightened by the phrase "UDP
> realtime" which was mentioned in this thread more than once. Looking
> at the desperation level of these posts I fear, that there are going
> to be real world products out already or available in the near future
> which are based on the profound lack of understanding of the
> technology they are based on.
Yes there are real-world product using real-time ethernet - not
necessarily UDP but for example anything EtherCAT based absolutely
needs to be able to send certain packets cyclically no more than
100 ms (or 10 ms or 2 ms) apart otherwise all hell breaks loose
with real-world connected hardware. The room for jitter is the
limit minus cycle the packets are being sent, which can be pretty
tight.
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
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.
There is nothing else on the network interface, but there usually
is another ethernet interface for non-realtime traffic. If some
of the locks involved is driver-wise instead of interface-wise
we already lost (I understand that this case would be the problem
of the driver and not the infrastructure).
If I am understanding the Nebojsa's worries wrong or if the
scenario cannot happen, please disregard.
Regards
--
Stano
--
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
