[dpdk-dev] [DPDK] lib/librte_ether: add comments RSS flags

[Andrew Rybchenko]

On 01/10/2018 10:38 AM, Thomas Monjalon wrote:
> 10/01/2018 03:15, Yang, Qiming:
>> From: Thomas Monjalon [mailto:thomas at 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