DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] ethdev flags and capabilities
@ 2018-05-01 20:41 Thomas Monjalon
  2018-05-02  5:28 ` Shahaf Shuler
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Monjalon @ 2018-05-01 20:41 UTC (permalink / raw)
  To: dev
  Cc: declan.doherty, ferruh.yigit, arybchenko, bruce.richardson, olivier.matz

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 (http://dpdk.org/commit/736b30ebf2)
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 (http://dpdk.org/commit/cac923cfea)
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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-dev] ethdev flags and capabilities
  2018-05-01 20:41 [dpdk-dev] ethdev flags and capabilities Thomas Monjalon
@ 2018-05-02  5:28 ` Shahaf Shuler
  0 siblings, 0 replies; 2+ messages in thread
From: Shahaf Shuler @ 2018-05-02  5:28 UTC (permalink / raw)
  To: Thomas Monjalon, dev
  Cc: declan.doherty, ferruh.yigit, arybchenko, bruce.richardson, olivier.matz

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




> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-05-02  5:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-01 20:41 [dpdk-dev] ethdev flags and capabilities Thomas Monjalon
2018-05-02  5:28 ` Shahaf Shuler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).