** Description changed: - Explanation : + [Impact] It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s - Reproducer : + [Test Case] + * Reproducer #1 $ iptables -F - $ echo 3 > /proc/sys/vm/drop_caches $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) + + * Reproducer #2 + $ iptables -F + $ time for f in `seq 1 2000` ; do iptables -A FORWARD ; done "list-addrs" script can be found here[3] - Note : + [Regression Potential] - * "iptables-restore" doesn't suffer of that netfilter regression, and - I'm also aware that "iptables-restore" is the favourite approach since - it is way more efficient than iptables that is executed over and over, - once for each policy one want to set, but since "/sbin/iptables" takes - vastly longer to perform with that commit, I think this need to be - address anyway. + * none expected, the patches have been proven to work on mainline + kernel, and was reviewed by a few netfilters maintainer + tested by + myself. - * I also tried with the latest and greatest iptables upstream code, and - got the same result. + Reference: + https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/ - Reference : + Patches: + https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/2394ae21e8b652aff0db1c02e946243c1e2f5edb + https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/722d6785e3b29a3b9f95c4d77542a1416094786a + https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/18b61e8161cc308cbfd06d2e2c6c0758dfd925ef + + [Other Info] + + * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "binary arp/ip/ip6tables" takes vastly longer to perform with that commit, I think this need to be address anyway. + + [Related Documents] + [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs
** Description changed: + [SRU JUSTIFICATION] + [Impact] It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s [Test Case] * Reproducer #1 $ iptables -F $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) * Reproducer #2 $ iptables -F $ time for f in `seq 1 2000` ; do iptables -A FORWARD ; done "list-addrs" script can be found here[3] [Regression Potential] - * none expected, the patches have been proven to work on mainline + * none expected, the patches have been proven to work on mainline kernel, and was reviewed by a few netfilters maintainer + tested by myself. Reference: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/ Patches: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/2394ae21e8b652aff0db1c02e946243c1e2f5edb https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/722d6785e3b29a3b9f95c4d77542a1416094786a https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/18b61e8161cc308cbfd06d2e2c6c0758dfd925ef [Other Info] - - * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "binary arp/ip/ip6tables" takes vastly longer to perform with that commit, I think this need to be address anyway. + + * "iptables-restore" doesn't suffer of that netfilter regression, and + I'm also aware that "iptables-restore" is the favourite approach since + it is way more efficient than iptables that is executed over and over, + once for each policy one want to set, but since "binary + arp/ip/ip6tables" takes vastly longer to perform with that commit, I + think this need to be address anyway. [Related Documents] [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs ** Description changed: [SRU JUSTIFICATION] [Impact] It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. + + Note that the situation can also be reproduce with latest and greatest + upstream kernel v4.9-rc4. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s [Test Case] * Reproducer #1 $ iptables -F $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) * Reproducer #2 $ iptables -F $ time for f in `seq 1 2000` ; do iptables -A FORWARD ; done "list-addrs" script can be found here[3] [Regression Potential] * none expected, the patches have been proven to work on mainline kernel, and was reviewed by a few netfilters maintainer + tested by myself. Reference: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/ Patches: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/2394ae21e8b652aff0db1c02e946243c1e2f5edb https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/722d6785e3b29a3b9f95c4d77542a1416094786a https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/18b61e8161cc308cbfd06d2e2c6c0758dfd925ef [Other Info] * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "binary arp/ip/ip6tables" takes vastly longer to perform with that commit, I think this need to be address anyway. [Related Documents] [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs ** Description changed: [SRU JUSTIFICATION] [Impact] It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. Note that the situation can also be reproduce with latest and greatest upstream kernel v4.9-rc4. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s [Test Case] * Reproducer #1 $ iptables -F $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) * Reproducer #2 $ iptables -F - $ time for f in `seq 1 2000` ; do iptables -A FORWARD ; done + $ time for f in `seq 1 3000` ; do iptables -A FORWARD ; done "list-addrs" script can be found here[3] [Regression Potential] * none expected, the patches have been proven to work on mainline kernel, and was reviewed by a few netfilters maintainer + tested by myself. Reference: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/ Patches: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/2394ae21e8b652aff0db1c02e946243c1e2f5edb https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/722d6785e3b29a3b9f95c4d77542a1416094786a https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/18b61e8161cc308cbfd06d2e2c6c0758dfd925ef [Other Info] * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "binary arp/ip/ip6tables" takes vastly longer to perform with that commit, I think this need to be address anyway. [Related Documents] [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1640786 Title: netfilter regression introducing a performance slowdown in binary arp/ip/ip6tables Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Bug description: [SRU JUSTIFICATION] [Impact] It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. Note that the situation can also be reproduce with latest and greatest upstream kernel v4.9-rc4. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s [Test Case] * Reproducer #1 $ iptables -F $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) * Reproducer #2 $ iptables -F $ time for f in `seq 1 3000` ; do iptables -A FORWARD ; done "list-addrs" script can be found here[3] [Regression Potential] * none expected, the patches have been proven to work on mainline kernel, and was reviewed by a few netfilters maintainer + tested by myself. Reference: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/ Patches: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/2394ae21e8b652aff0db1c02e946243c1e2f5edb https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/722d6785e3b29a3b9f95c4d77542a1416094786a https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next/+/18b61e8161cc308cbfd06d2e2c6c0758dfd925ef [Other Info] * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "binary arp/ip/ip6tables" takes vastly longer to perform with that commit, I think this need to be address anyway. [Related Documents] [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1640786/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
