Can a Bottom half be scheduled from a kernel thread

Wed May 14 01:21:42 EDT 2014

On Wed, May 14, 2014 at 12:38 AM, Vishwas Srivastava
<vishu.kernel at gmail.com> wrote:
> 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.

I think you got confused with processing and "getting" the packet. To
get the packet most probably
there would be an interrupt handler. Sure that handler could kickstart
NAPI polling or not it's upto driver
however in order to get the packet you'll need to have an interrupt
handler, unless it's a loopback sort of
device where you generate and route the packets on the same system.

> 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 ?

Sure use whatever you like, but again as you mentioned you'll need to
have that skb
to give to thread. This getting the skb part would require you to code
either interrupt handler or you
can make that skb_orphan and wake up some thread that would do your
receiving part so in this receiving
done by thread case it's actually not going on wire.

> 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.

Sounds complex, but i guess you are trying to learn to use tasklet so
no harm. What I would suggest instead is in your
ndo->xmit callback , schedule a tasklet which you know clear some
imaginary flags of the device and then wake up
a thread to do any processing. Going the other way as you mentioned, i
guess in case you eventually want to do some
allocation work then in tasklet you'll be limited.
>
> 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.

No side affects as i mentioned, tasklet_schedule, tasklet_hi_schedule
don't sleep. Just see that code
pretty simple. But make sure to have spin_lock* protecting your lists
with the thread and tasklet.

>  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
>
>

-- 
        ---P.K.S