Optimizing tc filters

Optimizing tc filters

[John A. Sullivan III]

Hello, all.  Given that there are several ways to direct packets into
the appropriate queue, I was wondering which ways are generally more
efficient.  There seem to be a number of email discussions but nothing
authoritative.  From those discussions, it would seem that for most
corporate usage (as in more traffic than a home user) we would have from
most efficient to least efficient:

1) Mark the connection with CONNMARK and us --restore-mark to mark all
packets in the connection for classification via an fw filter

2) Use the iptables CLASSIFY target

3) u32 filter

4) Mark individual packets and use an fw filter - one email thread says
this is more efficient than #3

Is this correct?

Re: Optimizing tc filters

[Eric Dumazet]

Le samedi 10 décembre 2011 à 13:16 -0500, John A. Sullivan III a écrit :
> Hello, all.  Given that there are several ways to direct packets into
> the appropriate queue, I was wondering which ways are generally more
> efficient.  There seem to be a number of email discussions but nothing
> authoritative.  From those discussions, it would seem that for most
> corporate usage (as in more traffic than a home user) we would have from
> most efficient to least efficient:
> 
> 1) Mark the connection with CONNMARK and us --restore-mark to mark all
> packets in the connection for classification via an fw filter
> 
> 2) Use the iptables CLASSIFY target
> 
> 3) u32 filter
> 
> 4) Mark individual packets and use an fw filter - one email thread says
> this is more efficient than #3
> 
> Is this correct?

Unfortunately CONNTRACK is a bit expensive...

If you control applications, you also can use SO_MARK from them.

Re: Optimizing tc filters

[John A. Sullivan III]

On Sat, 2011-12-10 at 20:41 +0100, Eric Dumazet wrote:
> Le samedi 10 décembre 2011 à 13:16 -0500, John A. Sullivan III a écrit :
> > Hello, all.  Given that there are several ways to direct packets into
> > the appropriate queue, I was wondering which ways are generally more
> > efficient.  There seem to be a number of email discussions but nothing
> > authoritative.  From those discussions, it would seem that for most
> > corporate usage (as in more traffic than a home user) we would have from
> > most efficient to least efficient:
> > 
> > 1) Mark the connection with CONNMARK and us --restore-mark to mark all
> > packets in the connection for classification via an fw filter
> > 
> > 2) Use the iptables CLASSIFY target
> > 
> > 3) u32 filter
> > 
> > 4) Mark individual packets and use an fw filter - one email thread says
> > this is more efficient than #3
> > 
> > Is this correct?
> 
> Unfortunately CONNTRACK is a bit expensive...
> 
> If you control applications, you also can use SO_MARK from them.
> 
> 
> 
OK.  Does that mean that #1 is actually #4?

If we are using connection tracking in general to produce a "stateful"
firewall (let's just say we are - I certainly don't want to set off a
debate :) ), does that put #1 back on top as the most efficient since we
are incurring the conntrack overhead anyway or does the CONNMARK target
itself add considerable overhead? Thanks - John

Re: Optimizing tc filters

[Eric Dumazet]

Le samedi 10 décembre 2011 à 14:58 -0500, John A. Sullivan III a écrit :

> If we are using connection tracking in general to produce a "stateful"
> firewall (let's just say we are - I certainly don't want to set off a
> debate :) ), does that put #1 back on top as the most efficient since we
> are incurring the conntrack overhead anyway or does the CONNMARK target
> itself add considerable overhead? Thanks - John
> 

CONNMARK is very cheap, no extra overhead.

Re: Optimizing tc filters

[John A. Sullivan III]

On Sat, 2011-12-10 at 21:10 +0100, Eric Dumazet wrote:
> Le samedi 10 décembre 2011 à 14:58 -0500, John A. Sullivan III a écrit :
> 
> > If we are using connection tracking in general to produce a "stateful"
> > firewall (let's just say we are - I certainly don't want to set off a
> > debate :) ), does that put #1 back on top as the most efficient since we
> > are incurring the conntrack overhead anyway or does the CONNMARK target
> > itself add considerable overhead? Thanks - John
> > 
> 
> CONNMARK is very cheap, no extra overhead.
> 
> 
OK - so I'll assume that, if using conntrac anyway, the order of
efficiency is as I outlined and, if not, #1 sinks to the bottom.  If
that's not accurate, please let me know.  Thanks for your help - John