SNF_RSS_FLAGS can be specified to let the implementation know which IP/TCP/UDP fields are significant when generating the hash. By default, RSS is computed on IPv4/IPv6 addresses and source/destination ports when the protocol is TCP or UDP.
By default, SNF_RSS_FLAGS = (SNF_RSS_IP|SNF_RSS_SRC_PORT|SNF_RSS_DST_PORT).
In snf.h there is this definition:
enum snf_rss_mode_flags {
SNF_RSS_IP = 0x01, /**< Include IP (v4 or v6) SRC/DST addr in hash */
SNF_RSS_SRC_PORT = 0x10, /**< Include TCP/UDP SRC port in hash */
SNF_RSS_DST_PORT = 0x20 /**< Include TCP/UDP DST port in hash */ };
Sniffer10G's RSS hashing options only operate on the outermost headers in the presence of tunneling. If the packet is an IP packet and SNF_RSS_IP is desired, the IPs will be considered in the hash. If the IP packet is UDP or TCP, then the ports are considered in the hashing. If all the traffic is tunneled through only a few distinct UDP/TCP flows, then the hashing will only distribute through those outer UDP headers.
We parse VLAN and QinQ (i.e. VLAN over VLAN) but then any RSS is applied only if what follows is an IPv4/IPv6 header that is followed by a TCP/UDP header. This means that any form of TCP/UDP tunneling considers only the outermost headers.
For Ethernet frames bearing "non-hashable" traffic (e.g., MPLS or other non-Myricom supported packets), they are distributed to the lowest core id or ring 0. No packets get dropped based on the type of packet it is. The only drop cases are bad CRC32 or when there is an overflow (either the adapter and/or application cannot sustain the packet rate).
For more information on SNF_RSS_FLAGS, please read: How do I set and check the RSS flags with Sniffer10G?
