On 01/10/2018 10:38 AM, Thomas Monjalon wrote:
10/01/2018 03:15, Yang, Qiming:
From: Thomas Monjalon [mailto:tho...@monjalon.net]
07/01/2018 07:32, Shahaf Shuler:
Saturday, January 6, 2018 12:22 PM, Andrew Rybchenko:
[..]
#define ETH_RSS_PORT (1ULL << RTE_ETH_FLOW_PORT)
+/** Enable RSS offload on VXLAN packets */
#define ETH_RSS_VXLAN (1ULL << RTE_ETH_FLOW_VXLAN)
+/** Enable RSS offload on GENEVE packets */
#define ETH_RSS_GENEVE (1ULL << RTE_ETH_FLOW_GENEVE)
+/** Enable RSS offload on NVGRE packets */
#define ETH_RSS_NVGRE (1ULL << RTE_ETH_FLOW_NVGRE)
#define ETH_RSS_IP ( \
These comments just decode the define name and not that useful. What
would be really useful here is specification of which fields of the
packet headers are used to calculate hash especially in the case of tunnels.
+1.
Also maybe some more clarifications, for example:
1. What is the expected behavior when, for example, setting the
ETH_RSS_IPV6_EX and regular IPv6 packet arrives? is RSS apply on it?
2. What is the expected behavior from the PMD when not supporting one of
the RSS types?
For example most of the DPDK examples uses ETH_RSS_IP [1], however
very few devices actually supports each and every RSS type.
Assuming such configuration returns with no error, what should application
expect when unsupported packet type arrives.
#define ETH_RSS_IP ( \
ETH_RSS_IPV4 | \
ETH_RSS_FRAG_IPV4 | \
ETH_RSS_NONFRAG_IPV4_OTHER | \
ETH_RSS_IPV6 | \
ETH_RSS_FRAG_IPV6 | \
ETH_RSS_NONFRAG_IPV6_OTHER | \
ETH_RSS_IPV6_EX)
+1
We really need a detailed documentation of the.
I agree with your comments, but the same RSS configuration may have different
behavior(RSS offload and input set) in different driver.
This is a bug!
The API must have the same meaning for all drivers.
+1 yes, that's what applications expect
Of course, different hardware/drivers can and have specifics
which should be described in the driver documentation, but
default behaviour should be defined.
Adding driver specific information in rte_ethdev.h is not suitable.
So I think the best scheme is to update driver's document to detail the exact
behavior and add reference doc here.
It must be at least as detailed as lib/librte_mbuf/rte_mbuf_ptype.h.
Thanks
