On 3/10/2023 9:35 AM, Dongdong Liu wrote:
> From: Huisong Li <lihuis...@huawei.com>
>
> Currently, the setting of hash algorithm comes from the
> default configuration in driver and the rte_flow interface.
> The hash algorithm that is set to hardware in both ways is
> saved in hw->rss_info.conf.func.
>
> But the 'func' in struct rte_flow_action_rss is usually used
> in rte flow interface. And the ethdev ops interface may also
> set hash algorithm in the future. It is not appropriate and
> is a little messy for ethdev ops interface and driver default
> configuration to use struct rte_flow_action_rss. So we have
> to separate the RSS configuration from ethdev ops and rte
> flow interface to make codes more easier to maintain.
>
Agree that it is not ideal to have two different ways for same/similar
control path functionality in ethdev.
+Ori to discuss if this is a common problem and can be resolved in
ethdev layer.
I can see some of remaining patches are related to this ethdev / flow
API RSS separation. I will continue with this set, but I believe it is
better if this issue addressed in higher level.
> This patch separates hash algorithm by following ways:
> 1) 'hash_algo' in struct hns3_rss_conf is used for ethdev ops
> interface or default configuration in driver.
> 2) Add a 'rte_flow_hash_algo' field in struct hns3_rss_conf
> to save algorithm from rte flow interface. The main reasons
> are as follows:
> Currently, only the last rule is used to restore the rte
> flow rule. If 'func' in RSS action is 'DEFAULT', it means
> that this rule doesn't modify algorithm and driver need to
> save current algorithm for restoring algorithm during reset
> phase.
>
> Fixes: c37ca66f2b27 ("net/hns3: support RSS")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Huisong Li <lihuis...@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdo...@huawei.com>
<...>
