Can a Bottom half be scheduled from a kernel thread

[Vishwas Srivastava]

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 at gmail.com>wrote:

> On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava
> <vishu.kernel at 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 at gmail.com>
> > wrote:
> >>
> >>
> >> On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel at 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 at kernelnewbies.org
> >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >> >
> >
> >
>
>
>
> --
>         ---P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140514/d37f1826/attachment.html