Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Steven Rostedt <rostedt@goodmis.org>]

On Sat, 2004-12-11 at 20:50 +0100, Esben Nielsen wrote:
> Linux relies on soft IRQ for delivering packets to the listening
> protocol stacks. That is a problem because you can't just boost the
> priority of soft-IRQ without boosting a lot of things.
> 
> With IRQ-threading the design could be changed such the IRQ thread does
> the job directly. But that will make the whole IRQ thread drive the
> protocol stack as well :-(
> 
> It all depends on what your requirements are. Maybe you can handle
> "driving" the whole IP stack before handling the RT packet - maybe not.
> 
> How did you handle it in your thesis?
> 

I had an irq threaded kernel, and all softirqs where handled by the
softirqd thread. I created two more threads that would handle the
sending and receiving of the packets.  Here's how it worked: 

Each packet had an ip option added that stated the priority of the
packet. (of course the priorities of each machine connected must have
this protocol and priorities mean the same).

When received, the interrupt (in interrupt context not a thread) would
look to see if it was an RT packet. If it was, it placed it on a rt
received queue and woke up the receive thread. If needed it would raise
the priority of that thread. If the packet was not RT, it went the
normal route (placed on the queue for the softirq to handle).

The packet queue was a heap queue sorted by priority. The parts of the
TCP/IP stack was broken up into sections. The receive thread would only
process the packet on top of the queue. At the end of the section, it
would check to see if the queue changed and then start processing the
packet on top, if a higher packet came in at that time.  So the packets
on the queue had a state attached to them.  When the packet eventually
made it to the process waiting, it was then handled by that process. So
if a process was waiting, the process would have been woken up and it
would handle the rest of the processing. Otherwise the receive thread
would do it up to where it can drop it off to the processes. I set the
packet to be once less priority of the process it was sent from and the
one it was going to.

The sending was done mostly by the process, but if it had to wait for
some reason, the sending thread would take over.

This was mostly academic in nature, but was a lot of fun and interesting
to see how results changed with different methods.


> 
> > 
> > I just wanted to bring up this discussion, I guess a general approach is
> > too difficult and not worth the effort.
> >
> 
> If you can think up something there is no harm in trying it :-)
>  

If I ever think of something, I would not hesitate on implementing
it ;-)

> > Thanks,
> > 
> > -- Steve
> > 
> Esben
> 
>