On 08.11.2013 12:30, Thomas Gleixner wrote:
> 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 did not meant the priority inversion in the strict thread running/blocked
sense. If the
On 08.11.2013 11:51, eg Engleder Gerhard wrote:
> In my situation the transmission of the packet from the high-prio
> thread is delayed until the low-prio thread is scheduled again.
is true then to me it is a kind of priority inversion.
It is understood that the default implementation will not change
the order of packets already queued for transmission.
> 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,
Fair enough.
> Hell no, there is no way to cure blissful ignorance with kernel
> patches.
The thing is that the userspace developers assume things. In this
case they assume that if a higher prio thread wants to send
a network packet and the send() returns, the maximum time until
that one packet gets out on the wire is the time all the already
queued packets need to get out. If this is true, I'm perfectly
fine - but from what Nebojsa and Gerhard are writing I have
my doubts and I am a bit scared as it can affect what we are
doing. As my job is not a kernel developer, I have to trust
others on this...
If not, I would not call it ignorance. This is IMHO a reasonable
assumption.
Thanks
--
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
