Hi Anton, Jozsef! If comfortable, then please reply! -Akshat On Mon, Sep 7, 2015 at 6:26 PM, Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote: > 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
