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/34ff088cc24159c9fa6e61242efb76d0289b4e37 > > ``` > 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. [1] https://patchwork.dpdk.org/project/dpdk/patch/20231103062606.2632012-12-chaoyong...@corigine.com/
