10/01/2018 03:15, Yang, Qiming: > From: Thomas Monjalon [mailto:[email protected]] > > 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. > 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
