hi! I am sorry to say but I am unable to comprehend that. Can you give an example? On Mon, Sep 7, 2015 at 6:22 PM, Anton Danilov <littlesmilingcloud@xxxxxxxxx> wrote: > Hello. > You can use the firewall mark as tc classid with fwmark filter. > It can interpret fwmark as tc classid. So, you can use this feature > inside your ipset/iptables/tc rules. > > 2015-09-07 15:09 GMT+03:00 Akshat Kakkar <akshat.1984@xxxxxxxxx>: >> 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 > > > > -- > Anton. -- 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
