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:db...@vmware.com]
Sent: Wednesday, July 12, 2017 10:55 PM
To: users@dpdk.org
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

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 ?




Reply via email to