Re: virtio: RSS support capa

[Ferruh Yigit <ferruh.yigit@amd.com>]

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.rybchenko@oktetlabs.ru]
>>>> On 9/7/24 23:55, Morten Brørup wrote:
>>>>>> From: Morten Brørup [mailto:mb@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.