Hello, all. Would it be correct to assume that tc filter hash tables are like iptables user defined chains and can be used to reduce the number of evaluations which must be made for each packet or is there significant additional overhead incurred by such hash tables? For example, we wanted to shape VoIP packets in ingress to our PBX from both VPN and direct Internet connections. Since the ifb interface gets the packet before NAT, we must account for both the public and internal destination addresses. We also need to match several possible port ranges to match any UDP ports over 4096 because of the way tc filter ranges are masked. So we did the following: # UDP tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 handle 217: u32 divisor 1 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 match ip protocol 17 0xff link 217: offset at 0 mask 0x0f00 shift 6 plus 0 That is, we created a hash table for all UDP packets with an accurate pointer to the beginning of the UDP header. # VoIP - UDP packets to the VoIP network under 256 Bytes over port 1024 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 handle 317: u32 divisor 1 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 217:0 match ip dst 172.x.x.0/24 match u16 0 0xffc0 at 2 link 317: tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 217:0 match ip dst 208.z.z.z match u16 0 0xffc0 at 2 link 317: That is, we create another hash linked from the UDP hash table so we only have to evaluate the IP type once and dump all small packets destined for either the NAT or real address to that hash table tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 317:0 match udp dst 32768 0x8000 at nexthdr+2 flowid 20:20 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 317:0 match udp dst 16384 0x4000 at nexthdr+2 flowid 20:20 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 317:0 match udp dst 8192 0x2000 at nexthdr+2 flowid 20:20 tc filter replace dev ifb0 parent 20:0 protocol ip prio 2 u32 ht 317:0 match udp dst 4096 0x1000 at nexthdr+2 flowid 20:20 And then create filters for the various port ranges. We figured this way, we only had to evaluate the IP protocol once instead of two or three times; we only had to evaluate the destination address and packet size once instead of twice, and needed only four packet size rules instead of four for each IP address. Is this a proper use of hash tables or have I really abused the concept? Thanks - John -- 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
