It is possible - I'm afraid that pref works only at toplevel. It probably doesn't inside u32's hashtable. I'm not sure it is my feeling from reading sources. However position matters here. You can try to change it - IIRC the first match counts. devik On Tue, 9 Apr 2002, Mihai RUSU wrote: > Hi > > If using hash filters like the ones below does the prio/pref parameter > work? > > tc filter add dev eth0 parent 1:0 handle 2: protocol ip u32 divisor 256 > tc filter add dev eth0 parent 1:0 protocol ip u32 ht 800:: match ip > dst 0/0 hashkey mask 0x000000ff at 16 link 2: > > tc filter add dev eth0 parent 1:0 prio 10 protocol ip u32 ht 2:4 > match ip dst 1.2.3.4/32 flowid 1:20 > tc filter add dev eth0 parent 1:0 prio 5 protocol ip u32 ht 2:4 > match ip dst 1.2.3.4/32 flowid 1:10 > > Well, it doesnt work. The kernel send the traffic to flowid 1:20 not 1:10. > The second filter which has a better priority isnt checked before the > first one, in fact it seems that in a hash table the filters are checked > in their order of creation without any consideration of the prio/pref > parameter. This doesnt happen if I dont use hashes. > > Is it a bug? Or can I do something to workarround that without, reordering > of filters position? > > Thanks > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
