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> <...>