For ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP
each expand out to a set of packet type bitmasks in dpdk
ETH_RSS_IP expands to:
ETH_RSS_IPV4 | \
ETH_RSS_FRAG_IPV4 | \
ETH_RSS_NONFRAG_IPV6_OTHER | \
At least for Fortville these are converted into register writes by the driver
in a straightforward manner. For FVL it's written to PFQF_HENA register and the
"Intel® Ethernet Controller XL710 Datasheet" section 7.1.2 Packet Types and
Input Set describe exactly what fields are included in the hash for different
However, different NICs may do different things and DPDK has to work with those
From: Darrell Ball [mailto:db...@vmware.com]
Sent: Wednesday, July 12, 2017 10:55 PM
Cc: Kavanagh, Mark B <mark.b.kavan...@intel.com>; Stokes, Ian
<ian.sto...@intel.com>; Kevin Traynor <ktray...@redhat.com>; O Mahony, Billy
<billy.o.mah...@intel.com>; Chandran, Sugesh <sugesh.chand...@intel.com>;
Bodireddy, Bhanuprakash <bhanuprakash.bodire...@intel.com>
Subject: RTE RSS configuration
OVS-DPDK uses a RTE RSS hash configuration of
ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP
I want to get an idea of expected guarantees of bounds of behavior if any.
I am trying to understand the lower bound of fields that could go into the RSS
For example, could the RSS hash just be based on L3 (ipv4 or ipv6) as best
effort and the
RSS valid flag be still set to true ?
Or, is it guaranteed that if L4 fields are not supported that the RSS valid
flag will be false ?
On the flip side could we be getting something else included as well like L2
(DA and SA, for example) implicitly ?