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@xxxxxxxxx> wrote:
On Tue, May 13, 2014 at 2:18 PM, Vishwas SrivastavaI think by the next tick it would run. Since when you do
<vishu.kernel@xxxxxxxxx> 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?
>
tasklet_schedule you are setting the softirq pending
flag.
Really depends, what I think is that you still wouldn't want to do too
> 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??
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.
queue_delayed_work?
> 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?
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@xxxxxxxxx>
> wrote:
>>
>>
>> On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@xxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxx
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >
>
>
---P.K.S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
