Yes, that sounds cool. But if you see, for Linux versions >= 3.4.1 some of the network drivers do not use the softirq or NAPI interface, but instead use a kernel thread to process the received packets. In the situation like this, whatever packets are processed by the kernel thread, i just want to enqueue them in a software Q and want to deque them and transmit them at some later point of time. Is it okay to use tasklet for this purpose ? So essentially what i would be doing is something like this ... 1: Kernel thread will process the packets and will give me "skb" 2: i will enqueue this skb in SW Q and schedule a tasklet. 3: when kernel will decicde to run the tasklet, in the handler function of the tasklet, i will dequeue packets and will transmit it to another interface. Since in this implementation, i will schedule a tasklet from a kernel thread, i am a bit concerned if this approach is all right and am not sure if scheduling a tasklet from a kernel thread has any side effects. Probably now my problem is more clearer. Appreciate the response and suggestions of the experts. On Tue, May 13, 2014 at 3:28 PM, Pranay Srivastava <pranjas@gmail.com>wrote:
On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava <vishu.kernel@gmail.com> wrote:
Appreciate the quick response..
Hi All, i am concerned about the scheduling the tasklet. The running of the tasklet is anyway controlled by the kernel at its own dissertation. But scheduling can be done from anywhere?? Correct?
I think by the next tick it would run. Since when you do tasklet_schedule you are setting the softirq pending flag.
Also can Tasklets can be used for "any" deferred work or it is strictly stick to the work which can not be done in the "top" half??
Really depends, what I think is that you still wouldn't want to do too much in tasklet, if it's heavy processing better give it a work-queue. So basically use tasklet as a breakup of your top half only. That timely things still are done quick indeed just not that quick.
For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this? queue_delayed_work? or maybe you can do just a kthread_create only for the thread and wakeup_process(<your_kthread>) when you want to run it.
You can do anything inside the code that's upto you, only rule is no sleepy things, and no copy_to_ or copy_from both can sleep and both require process context which you don't have. Besides the no sleeping rule, you can do whatever you like. By scheduling, I mean scheduling the current code by explicitly calling schedule or some other sleeping function call. But you can wake_up, tasklet_schedule, complete, complete_all etc.
you can do kmalloc, don't forget GFP_ATOMIC, but no vmalloc. You can do memcpy, but no copy_to/copy_from
On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ---P.K.S