On 9/11/2024 3:02 PM, Ferruh Yigit wrote: > On 9/11/2024 2:20 PM, Thomas Monjalon wrote: >> 11/09/2024 14:17, Morten Brørup: >>> From: Andrew Rybchenko [mailto:andrew.rybche...@oktetlabs.ru] >>>> On 9/7/24 23:55, Morten Brørup wrote: >>>>>> From: Morten Brørup [mailto:m...@smartsharesystems.com] >>>>>> dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_RSS_HASH; >>>>> >>>>> Or perhaps I'm misunderstanding this capability flag. >>>>> >>>>> I thought it indicated RSS ability, i.e. multi-queue, effectively >>>>> shadowing >>>> rte_eth_conf.rxmode.mq_mode RTE_ETH_MQ_RX_RSS_FLAG. >>>>> But maybe it doesn't. Maybe it indicates the ability to store the RSS hash >>>> value in the mbuf. >>>>> >>>>> The RTE_ETH_RX_OFFLOAD_RSS_HASH flag is completely undocumented. >>>>> >>>>> Can someone please clarify? >>>>> >>>> RTE_ETH_RX_OFFLOAD_RSS_HASH means that the driver can provide RSS hash >>>> value in mbuf (it makes sense if HW can provide it to the driver). >>> >>> OK, thanks. >>> >>> Then what indicates this ethdev capability: Use RSS to distribute packets >>> into multiple RX queues? >>> I.e. what to check before setting >>> rte_eth_conf.rxmode.mq_mode=RTE_ETH_MQ_RX_RSS_FLAG? >> >> It is supposed to be implemented by all DPDK drivers I think. >> Is there any case where RSS is not supported? >> > > Hi Morten, > > There is no formal capability reporting support in ethdev [1]. > > `struct rte_eth_dev_info::[rt]x_[queue]_offload_capa` uses > RTE_ETH_RX_OFFLOAD_* flags, and they are for limited scope, only to > report the offloading capability of device. > > Also some capability reporting distributed to > - struct rte_eth_dev_info::dev_capa (RTE_ETH_DEV_CAPA_*) > - struct rte_eth_dev_info (various files like speed_capa) > - struct rte_eth_dev_data::dev_flags (RTE_ETH_DEV_*) > > > Programmatically there is no way for device to report RSS support. > The .ini file has "RSS hash" feature, which covers RSS support, please > check 'features.rst'. > >
[1] // forgot the label for above pointer > We mentioned formal capability reporting a few times in the past, but > this is a big task to take, specially with all historical usages. > Two things specially bothers me: > 1. When we need a capability, since there is no dedicated place for it, > it finds itself one of above locations, mostly in dev_info. > 2. 'struct rte_eth_dev_info' has not defined role, it is combination of > the status, configuration and capability reporting. With more > capabilities hitting it, it is becoming a more mixed, central struct > that many features depends on.
