I test it on centos 7 fresh image, but still the same behaviour. So its either a feature set or a bug? But reason behind it to be a feature is not clear. Can anyone throw light at it? Besides, how (in my actual case of kernel upgrade) come simple kernel upgrade i.e. installation of kernel.rpm causes this behaviour to be infused in tc? Does upgrading kernel automatically upgrades tc (or iproute)? I dont think so... But then how it all happened? Please help ... Its getting pretty tricky out here ... On Thu, Aug 20, 2015 at 5:21 PM, Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote: > I thinks its a Bug!!! > > When I am deleting in hashtable other than 800: then it is deleting > all filters but in 800: it is deleting only the specified filter > > For example, following set of commands create a hashtable 15: and add > 2 filters to it. > > tc filter add dev eth0 parent 1:0 prio 5 handle 15: protocol ip u32 divisor 256 > tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:2 u32 > ht 15:2: match ip src 10.0.0.2 flowid 1:10 > tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32 > ht 15:2: match ip src 10.0.0.3 flowid 1:10 > > Now following command DELETES ALL THE FILTERS ! > tc filter del dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32 > > O/p of tc filter show eth0 is this case is blank. As all filters are deleted. > > > However, similar commands when executed for hashtable 800: is deleting > only the specified filter > tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32 > ht 800:0: match ip src 10.0.0.2 flowid 1:10 > tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:3 u32 > ht 800:0: match ip src 10.0.0.3 flowid 1:10 > > tc filter del dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32 > > Above mentioned command only deletes single filter. > O/p of tc filter show eth0 is 2nd case is > > filter parent 1: protocol ip pref 5 u32 > filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1 > filter parent 1: protocol ip pref 5 u32 fh 800::3 order 3 key ht 800 > bkt 0 flowid 1:10 > match 0a000003/ffffffff at 12 > > > > > > > > On Thu, Aug 20, 2015 at 4:04 PM, Andy Furniss <adf.lists@xxxxxxxxx> wrote: >> Akshat Kakkar wrote: >>> >>> I am running sl6.3 (i.e. kernel 2.6.32-279). I upgraded the kernel >>> (and only kernel) using elrepo to kernel 4.1.4. >> >> >> You won't get new features without updating TC - but your test case on >> my setup still deletes all the filters with matching tc. >> >>> Now when I boot with this new kernel, and try to delete specific tc >>> filter, it is not happening. It is instead deleting all the filters. >>> Following is the commanf I am trying, >>> >>> tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3 >>> u32 >> >> >> But earlier you found that handle alone wasn't unique so you should have >> used the whole command line that you added. >> >> Saying that it still deletes all, so that wasn't it. >> >>> It is behaving exactily as the command without handle, i.e. like >>> >>> tc filter del dev eth1 protocol ip parent 1: prio 5 >> >> >> It maybe a bug or it maybe that old kernel was unsafe letting you delete >> something that is going to get hashed to. >> >> FWIW using replace/change + full command (with eg. flowid changed) works >> for me, but I didn't find a way to change anything else - which doesn't >> mean there isn't a way, just that I am not familiar with >> hashing/advanced tc. >> >> Historically I always used to just remove the root qdisc and start again >> to change something, as it was safer/less error prone. If you have 000s >> of rules then use batch mode which will be way, way, faster than >> inputting them with a script. -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
