[dpdk-dev] ethdev flags and capabilities

[Shahaf Shuler]

Tuesday, May 1, 2018 11:41 PM, Thomas Monjalon:
> Subject: [dpdk-dev] ethdev flags and capabilities
> 
> Since DPDK 18.05-rc1, we have 2 new fields in rte_eth_dev_info:
> 	const uint32_t *dev_flags;
> 	uint64_t dev_capa;
> 
> The field dev_flags
> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> dk.org%2Fcommit%2F736b30ebf2&data=02%7C01%7Cshahafs%40mellanox.c
> om%7C16eef57203764ae7fc2208d5afa3e448%7Ca652971c7d2e4d9ba6a4d149
> 256f461b%7C0%7C0%7C636608040838595097&sdata=u6Vxc6hK6cdWprool%2
> FtZZN6GuVi72gg0Uvxenf6d5r0%3D&reserved=0)
> is a pointer to rte_eth_dev_data.dev_flags for these bits:
> 	RTE_ETH_DEV_INTR_LSC
> 	RTE_ETH_DEV_BONDED_SLAVE
> 	RTE_ETH_DEV_INTR_RMV
> 	RTE_ETH_DEV_REPRESENTOR
> 
> The field dev_capa
> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> dk.org%2Fcommit%2Fcac923cfea&data=02%7C01%7Cshahafs%40mellanox.c
> om%7C16eef57203764ae7fc2208d5afa3e448%7Ca652971c7d2e4d9ba6a4d149
> 256f461b%7C0%7C0%7C636608040838595097&sdata=YyB0S2vzSQgXpU4XP5H
> YEBb%2B35jUnGGOEbyWR4tsfxs%3D&reserved=0)
> is an integer for these bits:
> 	RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP
> 	RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP
> 
> How can we merge them?
> Should we move the capabilities in rte_eth_dev_data.dev_flags?
> Or do we want to keep the capabilities in rte_eth_dev_info?
> Is it OK to use pointers in rte_eth_dev_info or should we make a copy of
> rte_eth_dev_data fields?
> 
> We need to take a decision before RC3. Thanks

As I wrote on the comments on one of the series[1]

I think the first stage is to distinguish between an attribute of a port and capability of a port. 
e.g. REPRESENTOR is port attribute, while supporting interrupts is capability. 

So I think we still need the two fields, but need to make some order.

1. Capabilities should have RTE_ETH_DEV_CAPA prefix and attributes should have RTE_ETH_DEV_ATTR prefix. 
2. dev_flags is not a good name. flags is too generic word.
3. RTE_ETH_DEV_BONDED_SLAVE should not be exposed to application. 


[1] http://dpdk.org/ml/archives/dev/2018-March/094146.html




>