2016-10-31 11:02 GMT-07:00 Michael Ma <make0...@gmail.com>: > 2016-10-28 14:52 GMT-07:00 Michael Ma <make0...@gmail.com>: >> 2016-10-28 14:48 GMT-07:00 Stephen Hemminger <step...@networkplumber.org>: >>> On Fri, 28 Oct 2016 14:45:07 -0700 >>> Michael Ma <make0...@gmail.com> wrote: >>> >>>> 2016-10-28 14:38 GMT-07:00 Stephen Hemminger <step...@networkplumber.org>: >>>> > On Fri, 28 Oct 2016 14:36:27 -0700 >>>> > Michael Ma <make0...@gmail.com> wrote: >>>> > >>>> >> Hi - >>>> >> >>>> >> Currently IFB uses tasklet to process tx/rx on the interface that >>>> >> forwarded the packet to IFB. My understanding on why we're doing this >>>> >> is that since dev_queue_xmit() can be invoked in interrupt, we want to >>>> >> defer the processing of original tx/rx in case ifb_xmit() is called >>>> >> from interrupt. >>>> > >>>> > dev_queue_xmit is only called from interrupt if doing netconsole. >>>> > > In fact this doesn't seem to explain since if the original path is tx > and the context is interrupt, IFB will call dev_queue_xmit as well so > the context can be interrupt in that case. > > Then tasklet is still unnecessary. > >>>> OK - so the reason is that netif_receive_skb() can only be invoked >>>> from softirq and we have to use tasklet in IFB to guarantee this. >>>> >>>> Then if the original path is rx, tasklet is unnecessary because >>>> ifb_xmit() is invoked from netif_receive_skb() which is always in the >>>> softirq context, right? >>> >>> The other reason is to avoid deep kernel callstacks
I see - this seems to be the ultimate reason but in case we know the actual IFB configuration is simple then tasklet can still be avoided, right?
