On Wed, Jan 09, 2008 at 04:09:54AM -0500, Christopher Pohl wrote:
> I assume the default priority of stack Rx processing within io-pkt is 21.  

Yes, but it is (will be) configureable.

> Does the new thread model of io-pkt allow to prioritise the Rx processing of certain Ethernet frames ? 
> 
> In the easiest case, in a system with two physical Ethernet interfaces, I want to prioritise the Rx processing for all
 Ethernet frames which are received on one interface to a high priority vs. the rest of the system, e.g. 180, while 
frames received on the other interface continue to be Rx processed at prio 21. 
> 
> In a more sophisticated use case, I have a network driver and hardware which is capable of filing arriving frames 
according to their content in different DMA queues (think QoS) and I want different Rx processing priorities for 
different queues. The Rx processing should be prioritised up to the point, where the received packet data is fed into 
the stack's socket interface. 
> 
> What would I have to do in my network driver to instruct the stack to process certain Rx frames with increased 
priority ?

This hasn't been a design consideration up to this point.
It's been deemed more important to optimize thread context
switching and to this end all threads in io-pkt are
essentially equivalent.  In the general case, any thread in
io-pkt can process packets from any nic and later process
them up the stack.  In the current implementation, interrupt
cause pulses to be sent to channels.  These channels may be
received upon by any thread, one thread per channel at any
point in time.  If you have one nic per channel (thread) you
could be sure that whichever thread is handling the current
interrupt for that card is at a particular priority (1).  As
soon as you have more nics than channels, a thread may be
poked into handling interrupts by a nic other than the one
you're trying to special case the priority for.

(1) - This per card priority isn't currently implemented.


-seanb