Hi Darrell,
For ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP
each expand out to a set of packet type bitmasks in dpdk
./lib/librte_ether/rte_ethdev.h.
ETH_RSS_IP expands to:
ETH_RSS_IPV4 | \
ETH_RSS_FRAG_IPV4 | \
...
ETH_RSS_NONFRAG_IPV6_OTHER | \
ETH_RSS_IPV6_EX)
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
packet types.
However, different NICs may do different things and DPDK has to work with those
differences.
Regards,
/Billy.
From: Darrell Ball [mailto:[email protected]]
Sent: Wednesday, July 12, 2017 10:55 PM
To: [email protected]
Cc: Kavanagh, Mark B <[email protected]>; Stokes, Ian
<[email protected]>; Kevin Traynor <[email protected]>; O Mahony, Billy
<[email protected]>; Chandran, Sugesh <[email protected]>;
Bodireddy, Bhanuprakash <[email protected]>
Subject: RTE RSS configuration
Hi
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
hash.
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
fields
(DA and SA, for example) implicitly ?
