The network API (sockets etc) will be called by the user's task.
The network driver will run on the LP worker.
The socket calls run at the user priority, but no not actually do the
transfers. The just set up to do the transfer then wait for the
transfer to complete.
The transfer itself is initiated by the driver when there are buffers
and hardware resources available to do the transfer. So the whole
transfer runs on the LP work thread. The user thread is not involved
since it is just waiting all this time.
Other network actions (like most IOCTLs) are performed entirely on the
user thread.
Is there any limitation anywhere that dictates the relationship between
these two priorities?
Since they run synchronously and generally don't overlap in time, I
would say that the answer is no
In a properly turned real time system, you should never have two tasks
with the same priority. That breaks some of the fundamental assumptions
that support deterministic response times. If two tasks, A and B, have
the same priority, the response time of B will be scrambled, depending
on if A is running or not and how close A is to releasing the CPU to
allow B to run.
I think this shouldn't be an issue. Tasks with actual real-time
requirements are at higher and distinct priorities.
Everything else is at (or around) 100 with a round-robin policy. There are
no dead-lines to meet there, so I don't
care about any jitter.
Also there are two workers in the LP queue, not one.
So far I haven't noticed any availability issues, but something that looks
more like a dead-lock to me.
Yes, this is only for tasks with real time requirements. There should
be an segregation of priorities into two groups: All of the background
tasks that just need to do things as time permits should be in the lower
priority group. All task that have deadlines to meet should be in a
separate group of with higher priorities.
That way, then non-real-time background tasks will not interfere with
real time behavior.
Linux does that: All of the SCHED_OTHER tasks are lower priority than
any of the SCHED_FIFO tasks.
