[Click] About dynamic polling

[Joonwoo Park]

Hi all,

http://pdos.csail.mit.edu/pipermail/click/2009-February/007627.html
This is the latest patch but not sure if it's cleanly applicable even on old
2.6.24 + e1000e driver.

The promise of this NAPI patch is reduce overhead of PollDevice so the other
tasks can have more cpu cycle.
The *the other tasks* in here includes click task for sure as well as task
on the linux system like daemons and etc.

Above post has simple test result which shows that NAPI driver outperforms
pure polling driver, from packet size 128byte with 60% of cpu usage (just
12% cpu usage on 1024byte).
I believe NAPI driver will be working more effectively with more
sophisticated click
elements which is close to real use cases but haven't had chance to test
except with a simple rx counter elements.

Regards,
Joonwoo

On Wed, Apr 13, 2011 at 1:58 PM, Beyers Cronje <bcronje at gmail.com> wrote:

> That's the nature of a polling driver, it continually polls for packets. If
> the 100% utilization is such an issue for you then use FromDevice instead
> of
> PollDevice.
>
> Alternatively, a couple of years ago Joonwoo released a patch on the list
> to
> enable NAPI support for PollDevice, see
> http://permalink.gmane.org/gmane.network.routing.click/4405
>
> <http://permalink.gmane.org/gmane.network.routing.click/4405>These patches
> can also be downloaded at the bottom of page
> http://permalink.gmane.org/gmane.network.routing.click/4411
>
> <http://permalink.gmane.org/gmane.network.routing.click/4411>Not sure how
> valid these patches still are. Joonwoo, if you are reading this care to
> comment?
>
> Beyers
>
> On Wed, Apr 13, 2011 at 6:29 PM, shule ney <neyshule at gmail.com> wrote:
>
> > Ok, but once I start kernel click, it's always 100%, this should not be
> the
> > case that other tasks take the whole CPU.
> >
> > 2011/4/13 Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk>
> >
> > > But if click is only running as part of the kernel idle loop it
> > > shouldn't matter if the incoming packet rate is low , the CPU should
> > > switch to undertake what ever tasks are being demanded of it leaving
> > > click to run when it isn't doing anything else.
> > >
> > > adam
> > >
> > > On 13 April 2011 17:06, shule ney <neyshule at gmail.com> wrote:
> > > > What I'm thinking about is when the incoming packet rate is low, high
> > > rate
> > > > polling is not needed and you can make use of CPU to do other tasks,
> > > while
> > > > if you are always 100%, it's not possible.
> > > >
> > > > 2011/4/13 Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk>
> > > >>
> > > >> Unless I'm wrong, the click router exploits the idle cycles of the
> > > >> kernel to undertake its polling and other tasks. So unless you are
> > > >> wanting to undertake power management, why are you worried about the
> > > >> CPU being at 100% if click is just filling the idle tasks ? I am
> sure
> > > >> Eddie or someone else will correct me if I am wrong.
> > > >>
> > > >> adam
> > > >>
> > > >> On 13 April 2011 16:40, shule ney <neyshule at gmail.com> wrote:
> > > >> > Hi all:
> > > >> > I'm using intel 8254 family NIC, now I want to make the polling
> > > >> > mechanism dynamically(now it's constant rate polling and CPU usage
> > is
> > > >> > always
> > > >> > 100%), is there any suitable patch for my setups? Thanks very much
> > to
> > > >> > reply.
> > > >> > _______________________________________________
> > > >> > click mailing list
> > > >> > click at amsterdam.lcs.mit.edu
> > > >> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> > > >> >
> > > >
> > > >
> > >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>