Hi Adrian Turcu, On Wed, 6 Apr 2005 16:28:30 +0100, Adrian Turcu <adrian.turcu@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- lark _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
