> On 11/7/2023 1:42 AM, Chaoyong He wrote: > >> On 11/3/2023 6:25 AM, Chaoyong He wrote: > >>> Add the very basic rte_flow support for corenic firmware. > >>> > >>> Chaoyong He (11): > >>> net/nfp: move some source files > >>> drivers: add the structures and functions for flow offload > >>> net/nfp: add the control message channel > >>> net/nfp: support flow API for CoreNIC firmware > >>> net/nfp: support Ethernet flow item > >>> net/nfp: support drop flow action > >>> net/nfp: support IPv4 flow item > >>> net/nfp: support IPv6 flow item > >>> net/nfp: support TCP/UDP/SCTP flow items > >>> drivers: support MARK flow action > >>> net/nfp: support QUEUE flow action > >>> > >> > >> Recheck-request: iol-compile-amd64-testing, iol-unit-amd64-testing > > > > Seems both compile problems was introduced by this commit: > > https://github.com/Corigine/dpdk-next-net- > private/commit/34ff088cc2415 > > 9c9fa6e61242efb76d0289b4e37 > > > > ``` > > ethdev: set and query RSS hash algorithm Currently, rte_eth_rss_conf > > supports configuring and querying RSS hash functions, rss key and it's > > length, but not RSS hash algorithm. > > > > The structure ``rte_eth_dev_info`` is extended by adding a new field > > "rss_algo_capa". Drivers are responsible for reporting this capa and > > configurations of RSS hash algorithm can be verified based on the > > capability. The default value of "rss_algo_capa" is > > RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it. > > > > The structure ``rte_eth_rss_conf`` is extended by adding a new field > > "algorithm". This represents the RSS algorithms to apply. > > If the value of "algorithm" used for configuration is a gibberish > > value, drivers should report the error. > > > > To check whether the drivers report valid "algorithm", it is set to > > default value before querying in rte_eth_dev_rss_hash_conf_get(). > > > > Signed-off-by: Jie Hai <haij...@huawei.com> > > Signed-off-by: Dongdong Liu <liudongdo...@huawei.com> > > Acked-by: Huisong Li <lihuis...@huawei.com> > > Acked-by: Chengwen Feng <fengcheng...@huawei.com> > > Reviewed-by: Ferruh Yigit <ferruh.yi...@amd.com> ``` > > > > Which was not related with this patch series, I think? > > > > Yes, build error is not related with this patch, and it is fixed in next-net, > that is > why I tried to re-trigger the test, but it didn't work somehow [1]. > > Btw, this set is pending because of other change request, not because of the > reported build failure.
Oh, yes, I understand, the reason is I need to also update the 'nfp.ini' document. But we decide delay this patch set to the next version of DPDK as we found still need some modification to the logic of flower firmware. Thanks. > > > [1] > https://patchwork.dpdk.org/project/dpdk/patch/20231103062606.263201 > 2-12-chaoyong...@corigine.com/ >
