LARTC - Apr 2005 - MARK vs CLASSIFY with tc

Hello list,

I just wonder if someone did any performance tests (speed of processing the 
packets) or maybe could advise about this two scenario:

1. packets are marked with iptables and processed by tc using filters
2. packets are sent by iptables directly to tc using CLASSIFY chain, thus 
avoiding the tc filters

I had some thinking about these two ways of dealing with egress traffic and my 
logic says that the second should be faster to process the packets, but I 
might be wrong (I guess that being an iproute list there will be a lot of 
people in favour of the first - going even further by skipping iptables all 
together and using detailed filtering with tc).

This came up not just for fun nor that I saw some noticeable differences (not 
with the volume of traffic I''m having at the moment). I want to
regulate the
traffic from a multimedia server (RTSP) and everybody knows that audio/video 
traffic is very sensitive to variable latency and jitter with terrible 
end-user experience.

BTW I''m using HTB with SFQ, kernel 2.6.11.6, iproute2 ss050318 and
iptables
1.3.1. I used PFIFO before SFQ, but it seems that it takes quite a lot for 
the per stream bandwidth to be re-adjusted in case a new session opens and 
I''m already at the limit with the allocated slice from the total
available
pipe.

Thanks for taking your time thinking about this,
Adrian

Hi Adrian Turcu,


On Wed, 6 Apr 2005 16:28:30 +0100, Adrian Turcu
<adrian.turcu@gmvinteractive.com> wrote:
> Hello list,
> 
> I just wonder if someone did any performance tests (speed of processing the
> packets) or maybe could advise about this two scenario:
> 
> 1. packets are marked with iptables and processed by tc using filters
> 2. packets are sent by iptables directly to tc using CLASSIFY chain, thus 
> avoiding the tc filters
> 
> I had some thinking about these two ways of dealing with egress traffic and
my
> logic says that the second should be faster to process the packets, but I 
> might be wrong (I guess that being an iproute list there will be a lot of 
> people in favour of the first - going even further by skipping iptables all
> together and using detailed filtering with tc).
> 
It depends. You must consider the ruleset size and ruleset pattern.

For a large ruleset. It is not good to let every packet goes through the
rule and gets matched on some class. Think about 200 rules as an example.

It is better to have some kind of memory on a flow. If first packet of a
flow is classified as class C1, then it good to remember it and every
following packet of this flow is classified as class C1.

iptables/netfilter has CONNMARK support, which can be used to remember
an u32 number, and then set packet''s mark from this CONNMARK.

You can use such scheme

# if the flag is set, then restore connmark to mark
iptables -m connmark --mark value/mask -j CONNMARK --restore-mark --mask
   mask
# else, do the various match
iptables <match rule 1> -j CONNMARK --set-mark value/mask
iptables <match rule 1> -j RETURN
iptables <match rule 2> -j CONNMARK --set-mark value/mask
iptables <match rule 2> -j RETURN

Using this method, first packet is matched in O(N), but following
packets are matched in O(1).

So it is good to use iptables CONNMARK + MARK and tc fw filter.

But, if the ruleset is small, the difference should be small. You then
should choose the better one for you:

1. netfilter is more flexible;
2. tc filter is expected to be a little faster (I am not sure);

> This came up not just for fun nor that I saw some noticeable differences
(not
> with the volume of traffic I''m having at the moment). I want to
regulate the
> traffic from a multimedia server (RTSP) and everybody knows that
audio/video
> traffic is very sensitive to variable latency and jitter with terrible 
> end-user experience.
> 
> BTW I''m using HTB with SFQ, kernel 2.6.11.6, iproute2 ss050318 and
iptables
> 1.3.1. I used PFIFO before SFQ, but it seems that it takes quite a lot for 
> the per stream bandwidth to be re-adjusted in case a new session opens and 
> I''m already at the limit with the allocated slice from the total
available
> pipe.
> 
> Thanks for taking your time thinking about this,
> Adrian
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


-- 
  lark

Hi Wang Jian,

On Wed 06 Apr 2005 17:18, Wang Jian wrote:
> ...
> It depends. You must consider the ruleset size and ruleset pattern.
>
> For a large ruleset. It is not good to let every packet goes through the
> rule and gets matched on some class. Think about 200 rules as an example.
>
> It is better to have some kind of memory on a flow. If first packet of a
> flow is classified as class C1, then it good to remember it and every
> following packet of this flow is classified as class C1.
>
> iptables/netfilter has CONNMARK support, which can be used to remember
> an u32 number, and then set packet''s mark from this CONNMARK.
>
> You can use such scheme
>
> # if the flag is set, then restore connmark to mark
> iptables -m connmark --mark value/mask -j CONNMARK --restore-mark --mask
>    mask
Do you know if this mask here is able to match more then one mark? Like if 
say, to mach the marks range from 10000 (0x2710) to 20000 (0x4e20) the above 
will be:

iptables ... -m connmark --mark 0x2710/0xb1df -j CONNMARK --restore-mask 
--mask 0xb1df

where 0xb1df is (65535 XOR 20000). I guess is just XOR not XOR then +1 (this 
will give a mask value of 0xb1e0)  which I saw in some examples (google) of 
using the masking bits.

> # else, do the various match
> iptables <match rule 1> -j CONNMARK --set-mark value/mask
> iptables <match rule 1> -j RETURN
> iptables <match rule 2> -j CONNMARK --set-mark value/mask
> iptables <match rule 2> -j RETURN
>
it makes a lot of sense (have to review a bit the netfilter/iptables docs to 
bring myself up to speed) 

> Using this method, first packet is matched in O(N), but following
> packets are matched in O(1).
>
> So it is good to use iptables CONNMARK + MARK and tc fw filter.
>
> But, if the ruleset is small, the difference should be small. You then
> should choose the better one for you:
>
> 1. netfilter is more flexible;
> 2. tc filter is expected to be a little faster (I am not sure);
>
Thanks a lot,
Adrian