Hi Jozsef, Well you are right. Tc is not bad at evaluating large no. of rules but only if it is only fwmark rules. if it is using u32 filters, then performace do degrade severely. But this raise another doubt. Why is that so? Does simple fwmark filters are stored in hash? I am asking this because when I list the filters, there is no order in the list. So, are fwmark filters hashed? On Mon, Sep 7, 2015 at 5:39 PM, Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote: > On Mon, Sep 7, 2015 at 1:53 AM, Jozsef Kadlecsik > <kadlec@xxxxxxxxxxxxxxxxx> wrote: >> On Mon, 7 Sep 2015, Akshat Kakkar wrote: >> >>> I am suggesting an ipset hash:mark. >>> >>> Let me explain the motivation for this requirement: >>> >>> Assume we have 100 fw rules each marking packet as 1 to 100. I am >>> marking these to do traffic shaping, so that I need not check fw >>> matching conditions on every packet. Simple check on mark will be >>> sufficient. >>> iptables -t mangle -A Forward -j mark --restore-mark >>> iptables -t mangle -A Forward -m mark ! --mark 0 -j Accept >>> >>> iptables -t mangle -A FORWARD -i etho -o eth1 <firewall match >>> condition 1> -j MARK --set-mark 1 >>> . >>> . >>> iptables -t mangle -A FORWARD -i etho -o eth1 <firewall match >>> condition 100> -j MARK --set-mark 100 >>> >>> iptables -t mangle -A Forward -j Connmark --save-mark >>> >>> Next would be Filter table in Forward chain: >>> >>> iptables -t filter -m connmark ! --mark 0 -j Accept >>> >>> Note that as we are using connmark so we don't require related, >>> established rule. >>> >>> Now as I have to do bw shaping, so I need 100 tc filter rules, something like >>> >>> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1 >>> . >>> . >>> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 100 fw flowid 1:100 >>> (pardon me if I am wrong on syntax, idea is to give a feel of things) >>> >>> Now visualize traffic for rule 100. every pkt, in tc, will face a >>> delay equal 100T where T is the time to search first entry, as search >>> will be linear. Clearly this doesn't scale well when rule count moves >>> to thousand or more. >> >> tc is not bad at evaluating large number of rules. You should compare >> measured performances instead of assuming those. >> >>> However, if we have an ipset hash:mark with skbinfo support, then we >>> can store this mark - tc_class membership in it and then with a >>> constant lookup time we can scale to any no. of rules with cost being >>> only memory: >>> >>> ipset -N mark_tc_class_map hash:mark skbinfo >>> >>> ipset -A mark_tc_class_map 1 skbprio 1:1 >>> . >>> ipset -A mark_tc_class_map 4 skbprio 1:100 >>> >>> Please note that this is not storing mark in skbinfo but creating hash >>> of marks and then storing skbinfo against each mark. >>> >>> This ipset then we will use in mangle chain of postrouting >>> >>> iptables -t mangle -A Postrouting -j Set --map-set mark_tc_class_map --map-prio >>> With above rule we don't require those 100 tc filters mentioned above. >>> It all reduces to single rule in iptables and constant lookup time for >>> traffic shaping. >> >> You can already do this with the hash:ip,mark type if your rules allow >> reducing the conditions to IP address + mark value pairs. > > Well, I am having some mix of rules. Some are per IP bandwidth shaping > rules. So that I have taken care by hash:ip,mark. > However, there are other rules also, same as the one I have mentioned > above in example. So if I use tc filter for these rules, then my per > IP bandwidth limited traffic unnecessarily has to pass through all > those filters, which in the presence of ipset:mark will also go to tc > class directly. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
