可編譯易用的子產品化nf-HiPAC移植成功

由于早在上周三對這個周末就有了别的安排，要折騰空氣壓縮機，突然接到通知又要陪老婆去考試，幸虧周四靠晚上的時間完成了nf-HiPAC的移植工作。

       主要的TODO清單如下(主要是怕以上這個網頁也不在了...)：

Planned Features:

    implement better algorithmic core: The new core will dramatically reduce memory usage while at the same time improving the running time of insert and delete operations. The lookup performance will be improved radically too, especially for bigger rulesets. The concepts and the design are already developed, but the implementation is still in its very early stages

    add support for transactions

    add support for ipv6

    add support for MAC matches

    add functionality similar to iptables-restore

    add native support for set of ranges (e.g. ippools). Each native match is not a single range but instead a set of ranges, which makes a single rule more expressive

    consider making HiPAC available for NAT and mangle tables

    consider removing "rule prefix mismatch" limitation

    the next big step in the far future will be to extend the HiPAC algorithm to do classification with several stages. The HiPAC algorithm will then be capable of combining several classification problems in one data structure, e.g. it will be possible to solve routing, firewalling and traffic control with one HiPAC lookup. The idea is to shorten the packet forwarding path by combining e.g. fib_lookup and iptables filter lookup into one HiPAC query

Outstanding Bugfixes:

    fix handling of jump rules containing iptables matches (currently only some known iptables matches are allowed in jump rules)

    in the current version the number of rule updates per second is limited by the number of synchronize_rcu() calls per second. This slows down rule updates dramatically. Future releases will work around this problem and will offer full rule update speed again

Other Stuff:

    man page for userspace tool

    add more documentation

    more in-depth performance tests

模 塊化後的nf-hipac可以直接編譯出一個ko檔案以及一個使用者态的工具nf-hipac程式。值得注意的是，我在移植過程中，去掉了和 iptables子產品的關聯機制，這有兩方面的原因，第一是因為這方面的移植比較複雜，iptables的核心API在核心版本之間變化太大了；另一方面 就是還真的不怎麼會用到iptables的match/target子產品，如果使用了大量的iptables match/target子產品，還不如直接就用iptables呢，再者說，iptables子產品隻是延展了nf-hipac的功能，對其性能是一個打折 的過程。

       以下是子產品化移植工作遇到的一些問題：

需要将match/target操作進行移植，核心API變化太大，砍去。

這 部分比較容易。2.6.13版本的netlink的input回調函數參數是一個socket，建立者需要自己建立核心線程來從該socket的 queue中持續擷取skb并且維護queue本身，這部分工作在高版本核心中得到了簡化，因為input回調函數的參數就是skb本身，隊列的維護由 netlink系統完成。

在原始的nf-hipac中，為了節省記憶體，用了兩套記憶體管理方案，即mini alloc/free以及big alloc/free，在調試這部分的時候遇到了不少問題，加之現在記憶體沒必要那麼節省，我就統一采用了big alloc/free，也就是說統一在vmalloc區域進行配置設定。

說實話，2.6.32核心對net namespace的支援也隻是個半吊子，但無論如何接口已經适配了，這就是說我必須按照net namespace的要求來處理proc_net。

我隻是測試了2.6.32核心和3.9.6核心，對于其它版本的核心并沒有測試，這種風格也是拜ipset-6.23所賜，要知道，我也是一個很較真兒的人，有時候也會有點書生氣。

...

即便是不下載下傳tgz壓縮包，也可以通過打patch的方式建構編譯目錄。

建立一個nf-hipac空目錄并cd到它，然後執行：

patch -p1 < $path/nfhipac-1.0.0.patch

就 會将所有的檔案和目錄置于該目錄下，然後make;make install即可。注意，編譯的時候需要準備好你的目前核心版本頭檔案，連結到/lib/modules/`uname -r`/build。 最後給出一個比較長的patch，即nfhipac-1.0.0.patch檔案：51CTO下載下傳中心。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1581361