* [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).