[Bug 1328] New: Please allow ipset add and del via the /proc/net/xt_ipset mechanism

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Mon Mar 25 21:48:49 CET 2019


https://bugzilla.netfilter.org/show_bug.cgi?id=1328

            Bug ID: 1328
           Summary: Please allow ipset add and del via the
                    /proc/net/xt_ipset mechanism
           Product: ipset
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: default
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: murf at parsetree.com

I measure the xt_recent hash table's speed to enter an ip into the hash, and
compared with ipset add speed. recent, via this method:

echo +<addr> >/proc/net/xt_recent/DEFAULT

is 13 times faster than ipset add <addr>

Now, ipset has these advantages against recent:

recent has size limits you must define when you load the module. Ugh.
ipset, on the other hand, at least in the newer versions, (the ones NOT on
centos 6, btw), has no size limit.

So, a list of IP's with CIDRs, like voipbl, takes around 90 seconds to load the
63k ip's.  recent will do it in about 7 seconds. (well, estimated, as recent
can handle only 8k entries (or at least so it did over a year ago).)

Can you guys, someday, sometime, enable this other, faster way to load up the
ipset with multiple thousands of addresses?

You know, it might even be faster if you allow a whole batch of + and -addrs in
a file, to be dumped at a single shot:

cat ipfile > /proc/net/xt_ipset/someipset

Many thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190325/8cb79af1/attachment.html>


More information about the netfilter-buglog mailing list