[LARTC] u32 hashing bug?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm hashing on a non-octet boundary, and it doesn't seem to be working.

I've got this set of filters, that does work:

# root
tc filter add dev eth1 \
parent 1: protocol ip prio 2 \
u32


# ht
tc filter add dev eth1 \
parent 1: protocol ip prio 2 \
handle 2: \
u32 divisor 256


# flow
tc filter replace dev eth1 \
parent 1: protocol ip prio 2 \
\
u32 \
ht 2:65: \
match ip src 192.168.1.100 \
flowid 1:20


# link
tc filter add dev eth1 \
protocol ip parent 1: prio 2 \
handle 800::2 \
u32 \
ht 800:: \
match ip src 192.168.0.0/16 \
hashkey mask 0x000000ff at 12 \
link 2:


I changed just the hashkey mask on the "link" filter to:
hashkey mask 0x000ff000 at 12 \
and the hashtable on the "flow" filter to:
ht 2:80: \


Checking it in tc -r filter list dev eth1, I see that nothing but the hashkey and bucket changed.

I'd expect that it'd hash on the fourth and fifth bytes. But it doesn't match, and my traffic goes to the default bucket. I tried it with a hashkey mask of 0xff00 0000, 0x00ff 0000, 0x0000 ff00, and 0x0000 00ff (and ht's of c0, a8, 01, and 69, respectively); they all worked. I tried 0x0ff0 0000 and 0x000f f000 (ht's 0a and 80) without success.

Does this appear to be a bug? I don't have a patch, but I'll post one if I get one (or I'll recant my "bug" :) ).


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux