Hello again!
Lukas Razik wrote:
In my module I create a kernel thread with the thread handler
'rx_thread_action' (please see below).
(It polls a message queue which is provided by the driver of a SCI card
but that's unimportant.)
static inline void
rx_action(struct net_device *dev, u8 *data, int datalen) {
// encapsulate data...
...
write_timestamp(data);
// ...and pass it to upper levels
netif_rx(skb);
}
static int
rx_thread_action(void *d) {
...
while(!signal_pending(current)) {
...
if(receive(message_queue, buf, size,...)) {
rx_action(dev, buf, size);
}
. ...
}
...
}
Why does the kernel need such a long time (i.e. one jiffie) between the
calling of 'netif_rx()' and passing the message to the belonging user
space socket?
Is it because I call 'netif_rx()' in a kernel thread (in process
context) and normally it will be called by a network card driver in
interrupt context?
How could I get rid of this time loss?
I've read that the further processing won't be done by netif_rx() but by
netif_receive_skb() which is called by the softirqs...
So I thought that this:
...
netif_rx(skb);
yield();
...
would let the softirq subsystem to be processed by the softirqd threads
(my kernel thread has nice +19). But this was no solution because I've
got bad times again...
Now I do the following:
...
netif_rx(skb);
do_softirq();
...
and I get pretty good results.
So, I have these questions:
1. Why does the yield() call in my kernel thread not force the
proceeding of the softirqs?
2. Is it normally 'safe' to call do_softirq() in a kernel thread?
What should I take into account?
I hope someone of you can explain me these things.
Best regards,
Lukas
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
