[Click] Re: click v.s. NAPI

[Eddie Kohler]

Hi Zhigang,

> >From pure performance point of view, could you comment on
> the pros and cons between click pure polling and NAPI's
> mixed interrupt and polling for gigabit router/firewalls.

First I've heard of NAPI; just looked at the Usenix paper.  You should run
your own tests to evaluate NAPI vs. Click on your setup (and please report
them to the list!).  But generally speaking, a mixed interrupt/polling
system might be better than a pure-polling system for routers that
generally forward few packets.

Imagine a pure-polling system that isn't forwarding very many packets.  You
basically have a tradeoff: packet latency vs. CPU usage.  If you poll
frequently (even though most polls fail to do any work), you will catch
packets as soon as they arrive, but you will also take up a lot of CPU with
useless work.  If you poll infrequently (because most polls fail to do any
work), then packets may sit on the network card for a while before you
catch them, increasing forwarding latency.

The catch is that interrupts are _extremely_ expensive, at least in our
testing.  In fact, they are so expensive that it may not ever make sense
for a router to take one, unless it has like hundreds of ports.

Click's adaptive scheduler (--enable-adaptive) attempts to reduce the
CPU-usage problem by "dialing down" the CPU allocated to polling under
light load.  Clearly, this will increase forwarding latency.  But not by
very much (unless your user-level code is doing CPU-intensive stuff); and
that you can address by raising the clock interrupt rate.

I've cc'd Luigi Rizzo, who implemented a couple varieties of polling, and
mixed interrupt/polling, on FreeBSD.  Perhaps he could comment.

> Also, since click bypass linux stack, can I still use it with
> things like iptables, or I must use one of the click counterparts.

Use the Click counterparts -- but packets passed to Linux via the ToHost
element *will* go through iptables [I think].

Eddie