* Re: [dpdk-users] RTE RSS configuration
[not found] <518F5428-003C-4E07-BE49-18F99F3D681C@vmware.com>
@ 2017-07-13 8:56 ` Stokes, Ian
2017-07-14 15:03 ` O Mahony, Billy
1 sibling, 0 replies; 2+ messages in thread
From: Stokes, Ian @ 2017-07-13 8:56 UTC (permalink / raw)
To: Darrell Ball, users
Cc: Kavanagh, Mark B, Kevin Traynor, O Mahony, Billy, Chandran,
Sugesh, Bodireddy, Bhanuprakash, Loftus, Ciara
Adding Ciara to the thread.
Ian
From: Darrell Ball [mailto:dball@vmware.com]
Sent: Wednesday, July 12, 2017 10:55 PM
To: users@dpdk.org
Cc: Kavanagh, Mark B <mark.b.kavanagh@intel.com>; Stokes, Ian <ian.stokes@intel.com>; Kevin Traynor <ktraynor@redhat.com>; O Mahony, Billy <billy.o.mahony@intel.com>; Chandran, Sugesh <sugesh.chandran@intel.com>; Bodireddy, Bhanuprakash <bhanuprakash.bodireddy@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 ?
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [dpdk-users] RTE RSS configuration
[not found] <518F5428-003C-4E07-BE49-18F99F3D681C@vmware.com>
2017-07-13 8:56 ` [dpdk-users] RTE RSS configuration Stokes, Ian
@ 2017-07-14 15:03 ` O Mahony, Billy
1 sibling, 0 replies; 2+ messages in thread
From: O Mahony, Billy @ 2017-07-14 15:03 UTC (permalink / raw)
To: Darrell Ball, users
Cc: Kavanagh, Mark B, Stokes, Ian, Kevin Traynor, Chandran, Sugesh,
Bodireddy, Bhanuprakash
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:dball@vmware.com]
Sent: Wednesday, July 12, 2017 10:55 PM
To: users@dpdk.org
Cc: Kavanagh, Mark B <mark.b.kavanagh@intel.com>; Stokes, Ian <ian.stokes@intel.com>; Kevin Traynor <ktraynor@redhat.com>; O Mahony, Billy <billy.o.mahony@intel.com>; Chandran, Sugesh <sugesh.chandran@intel.com>; Bodireddy, Bhanuprakash <bhanuprakash.bodireddy@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 ?
^ permalink raw reply [flat|nested] 2+ messages in thread