Add destination address to hash computation in mac fanout
Under normal operation, mac worker fanout computes a hash which is then used to select the IP worker to which a given packet is sent for IP processing. The mechanism currently in use only hashes the source IP address and optionally the source and destination port numbers (for TCP, UDP, SCTP and ESP). This is adequate for unicast TCP or low rates of UDP (or other packet-oriented) data, however, it can become a problem when dealing with high rates of packet-oriented flows, especially for IP multicast for IPTV (or other kinds of high-volume multicast streaming).
IPTV streams frequently originate in specialized transmission equipment (such as DVB IRDs and digital content processors) which tend to stream many hundreds of megabits of video sourced at a single IP address and using a single source-destination port combo, instead differentiating each stream based on the destination multicast address. Consider, the following example of an IRD which streams out three different IPTV channels as UDP multicast streams:
10.0.0.5:1234 -> 22.214.171.124:1234
10.0.0.5:1234 -> 126.96.36.199:1234
10.0.0.5:1234 -> 188.8.131.52:1234
In each case, the current hashing algorithm would result in all packets being delivered to the same IP worker thread, which in turn can easily starve a single CPU of resources (in case the volume is sufficient, which in multimedia applications with several Gb/s worth of packet flow, is easy to achieve). On the other hand, switching to round-robin fanout can reorder packets, which for most digital TV applications is equivalent to the packets having been lost in transmission, resulting in unacceptable behavior.
This proposed patch, which is supposed to be applied on top of the patch for issue #918 from Dan McDonald (http://kebe.com/~danmcd/webrevs/918), implements a new value for mac_fanout_type in mac_sched.c:520, MAC_FANOUT_SRC_DST. When this value is in effect, we simply do a src+dst on the address portion of the packets in hash computation, resulting in correct fanout even for the above noted special case, while guaranteeing correct packet ordering. The default for the mac_fanout_type tunable is left at its original value, thus making sure that no existing systems would be affected by this change.