Re: kernel patching elimination

On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <[email protected]>wrote:

> Hi,
>
> I've got a few questions regarding the design of Click router:
> 1) Why does Click do kernel patching (and fixing include files via
> fixincludes.pl script) for g++ compiler instead of providing wrapper
> functions, surrounded by "extern "C" "? Or even some abstraction layer
> written in C?
>

kernel patching works very well.  As Lars stated, it is not possible to
directly include the kernel header files in a c++ file, for many different
reasons (the "::" operator, use of variables name "new", etc).  If an
abstraction layer was written in C, it would need to abstract *all* packet
access, which means that reading or writing any packet data would require
an extra layer of function calls, which would likely affect performance.


> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>

Depending on the version of linux, click will use many different hooks.  If
you have a specific recommendation for something that would be better than
the current hooks, patches would be appreciated!


> 3) Why doesn't Click use NAPI for device polling?
>

Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
"PollDevice" click element, which acts as an ethernet driver, was written
before NAPI existed.  It would probably be possible to build a high
performance framework that gave packets directly to click by somehow
leveraging NAPI like interfaces... it still might require compile time
changes though.

Basically I am looking into possibilities to eliminate kernel patching
> altogether and make it more independent/standalone.
>

On many versions of modern linux, kernel patching is not required, so I'm
not sure what you want to change.  Also, click can be run at userlevel in a
very standalone fashion.

Cliff