[dpdk-dev] [PATCH v4] app/testpmd: fix the default RSS key configuration

[Ferruh Yigit]

On 10/9/2020 7:27 PM, Ferruh Yigit wrote:
> On 10/9/2020 12:55 PM, oulijun wrote:
>>
>>
>> 在 2020/9/30 20:57, Ferruh Yigit 写道:
>>> On 9/24/2020 2:45 PM, Lijun Ou wrote:
>>>> It use the NIC valid default RSS key instead of the testpmd
>>>> dummy RSS key in the flow configuration when the RSS key is
>>>> not specified in the flow rule. If the NIC RSS key is
>>>> invalid, it will use testpmd dummy RSS key as the default
>>>> key.
>>>
>>> Can you please describe the impact, what fails without this fix?
>>>
>> Hi, Ferruh
>>    According to Phil Yang's suggestion, I've put the impact description in the 
>> cover letter.
>>     When a user runs a flow create cmd to configure an RSS rule
>> with specifying the empty rss actions in testpmd, this mean
>> that the flow gets the default RSS functions from the valid
>> NIC default RSS hash key. However, the testpmd is not set
>> the default RSS key incorrectly when RSS key is not specified
>> in flow create cmd.
>>     After the testpmd is started, run the flow create cmd without specifying 
>> the RSS hash key. Ensure that RSS hash key queried after
>> the RSS flow is configured is the same as the default key after the
>> testpmd is start.
>>
>>>>
>>>> Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API")
>>>> Cc: stable at dpdk.org
>>>>
>>>> Signed-off-by: Lijun Ou <oulijun at huawei.com>
>>>> ---
>>>> V3->V4:
>>>> -fix checkpatch warning and shorter commit content.
>>>>
>>>> V2->V3:
>>>> -fix checkpatch warning.
>>>>
>>>> V1->V2:
>>>> -fix the commit.
>>>> ---
>>>>   app/test-pmd/cmdline_flow.c | 8 ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
>>>> index 6263d30..e6648da 100644
>>>> --- a/app/test-pmd/cmdline_flow.c
>>>> +++ b/app/test-pmd/cmdline_flow.c
>>>> @@ -4312,6 +4312,7 @@ parse_vc_action_rss(struct context *ctx, const struct 
>>>> token *token,
>>>>           action_rss_data->queue[i] = i;
>>>>       if (!port_id_is_invalid(ctx->port, DISABLED_WARN) &&
>>>>           ctx->port != (portid_t)RTE_PORT_ALL) {
>>>> +        struct rte_eth_rss_conf rss_conf = {0};
>>>>           struct rte_eth_dev_info info;
>>>>           int ret2;
>>>> @@ -4322,6 +4323,13 @@ parse_vc_action_rss(struct context *ctx, const struct 
>>>> token *token,
>>>>           action_rss_data->conf.key_len =
>>>>               RTE_MIN(sizeof(action_rss_data->key),
>>>>                   info.hash_key_size);
>>>> +
>>>> +        rss_conf.rss_key_len = sizeof(action_rss_data->key);
>>>> +        rss_conf.rss_key = action_rss_data->key;
>>>
>>> 'rss_conf.rss_key_len' is the input parameter, it looks like it has been used 
>>> as the size of the 'rss_key', but as far as I can see it is not.
>>>
>> Yes, rss_key_len and rss_key is configured independently. In fact, when the 
>> user configures the rss_key， we should know rss_key_len.
>>> Because of this if 'info.hash_key_size' is bigger than 
>>> 'sizeof(action_rss_data->key)', won't PMD overwrite the stack for the 
>>> remaining bytes?
>> if info.hash_key_size and action_rss_data->key is set used RSS flow cmd when 
>> info.hash_key_size is bigger than sizeof(action_rss_data->key)， the driver 
>> will return an error.
>  >
> 
> How can driver return an error?
> Both 'rss_conf.rss_key_len' & 'rss_conf.rss_key' filled by driver, and driver 
> expect 'rss_conf.rss_key' is big enough to hold its key.
> Here 'rss_conf.rss_key' points to fixed size 'action_rss_data->key' array 
> without checking the driver key length.
> 
> Where this driver check happens, am I missing it?
> 
>>>
>>> Can you please check?
>>>
>>>> +        ret2 = rte_eth_dev_rss_hash_conf_get(ctx->port, &rss_conf);
>>>> +        if (ret2 != 0)
>>>> +            return ret2;
>>>
>>> If PMD not implemented the 'rss_hash_conf_get' dev_ops, should it fail the 
>>> RSS action?
>> Yes, When the RSS hash key is not specified in the RSS flow, ensure that the 
>> RSS hash key remains unchanged and is the same as that configured in the 
>> hardware when the testpmd is started.
> 
> OK, but this means any PMD not implemented dev_ops to get RSS key won't able to 
> use rte flow RSS action via testpmd, not sure if this is right.
> 
> What this patch does is read the device configured RSS key, and feed it back to 
> rte flow RSS action, to be sure device key is not changed.
> 
> Instead, can we update the rte flow RSS action to not change the key if it is 
> not provided, and don't provide one in the testpmd by default.
> 
> What do you think?
> 

cc'ed Ori for the rte flow related change suggestion.
@Ori, can you please check the problem this patch address and the suggestion above?