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
