On Wed, May 14, 2014 at 12:38 AM, Vishwas Srivastava <vishu.kernel@xxxxxxxxx> 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@xxxxxxxxx> > wrote: >> >> On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava >> <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? >> > >> >> 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@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 > > -- ---P.K.S _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
