Speeding Up Netfilter (by Avoiding Netfilter)

""

Imre Palik tried to speed up some of Linux's networking code but was met with stubborn opposition. Essentially, he wanted networking packets to bypass the netfilter code unless absolutely necessary. Netfilter, he said, was designed for flexibility at the expense of speed. According to his tests, bypassing it could speed up the system by as much as 15%.

Netfilter is a piece of infrastructure that gives users a tremendous amount of power and flexibility in processing and restricting networking traffic. Imre's idea was that if the user didn't want to filter network packets, the netfilter code shouldn't even be traversed. He therefore wanted to let users disable netfilter for any given firewall that didn't need it.

There was some initial interest and also some questions about how he'd calculated his 15% speed increase. Florian Westphal tried to reason out where the speedup might have come from. But David S. Miller put his foot down, saying that any speedup estimates were just guesses until they were properly analyzed via perf.

David absolutely refused to apply networking patches without a more reliable indication that they would improve the situation.

Imre explained his testing methods and asserted that they seemed sound to him. But Pablo Neira Ayuso felt that Imre's approach was too haphazard. He said there needed to be a more generic way to do that sort of testing.

David was completely unsatisfied by Imre's tests. Instead of trying to work around netfilter, even in cases where there were no actual filters configured, he said, the proper solution was to speed up netfilter so it wouldn't be necessary to bypass it. David said, "We need to find a clean and generic way to make the netfilter hooks as cheap as possible when netfilter rules are not in use."

David Woodhouse, on the other hand, felt that a 15% speedup was a 15% speedup, and we shouldn't look a gift horse in the mouth.

But, David M stood firm. The netfilter hooks were the fundamental issue, he said, and "I definitely would rather see the fundamental issue addressed rather than poking at it randomly with knobs for this case and that."

David W and others started hunting around for ways to satisfy David M without actually recoding the netfilter hooks. David W suggested having the hooks disable themselves automatically if they detected that they wouldn't be useful.

Ultimately there was no conclusion to the thread, although it seems clear that for the moment, Imre's code is dead in the water. The problem with that is that 15% really is 15%, and speedups are good even if they're not perfect. It's conceivable that no one will come up with a good way to fix netfilter hooks, and that Imre's patch will receive better testing and more meaningful performance numbers. At that point, it's possible even David M would say okay.

Note: If you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.

Zack Brown is a tech journalist at Linux Journal and Linux Magazine, and is a former author of the "Kernel Traffic" weekly newsletter and the "Learn Plover" stenographic typing tutorials. He first installed Slackware Linux in 1993 on his 386 with 8 megs of RAM and had his mind permanently blown by the Open Source community. He is the inventor of the Crumble pure strategy board game, which you can make yourself with a few pieces of cardboard. He also enjoys writing fiction, attempting animation, reforming Labanotation, designing and sewing his own clothes, learning French and spending time with friends'n'family.

Load Disqus comments

Corporate Patron

Linode Logo

 

Community Events

-
Portland, OR, USA
-
Las Vegas, NV, USA
-
Vancouver, Canada
-
Vancouver, Canada
-
Las Vegas, NV, USA