[dpdk-dev,v4,18/23] ethdev: Helper to map to struct rte_pci_device
Checks
Commit Message
PCI drivers could use this helper instead of directly accessing fields of
rte_eth_dev to map to rte_pci_device.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
---
lib/librte_ether/rte_ethdev.h | 10 ++++++++++
1 file changed, 10 insertions(+)
Comments
2016-12-21 16:09, Jan Blunck:
> PCI drivers could use this helper instead of directly accessing fields of
> rte_eth_dev to map to rte_pci_device.
[...]
> +/**
> + * @internal
> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
> + */
> +static inline struct rte_pci_device *__attribute__((always_inline))
> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
> +{
> + return eth_dev->pci_dev;
> +}
Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)?
I think we must try to avoid any PCI (or other bus) reference inside ethdev.h.
On Thu, Dec 22, 2016 at 4:21 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-12-21 16:09, Jan Blunck:
>> PCI drivers could use this helper instead of directly accessing fields of
>> rte_eth_dev to map to rte_pci_device.
> [...]
>> +/**
>> + * @internal
>> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
>> + */
>> +static inline struct rte_pci_device *__attribute__((always_inline))
>> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
>> +{
>> + return eth_dev->pci_dev;
>> +}
>
> Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)?
>
> I think we must try to avoid any PCI (or other bus) reference inside ethdev.h.
David requested to move it from rte_pci.h to rte_ethdev.h.
It could get forward declared here if one doesn't use it. On the other
hand the rte_pci.h would be required to include rte_ethdev.h if we
move it.
2016-12-22 19:13, Jan Blunck:
> On Thu, Dec 22, 2016 at 4:21 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-12-21 16:09, Jan Blunck:
> >> PCI drivers could use this helper instead of directly accessing fields of
> >> rte_eth_dev to map to rte_pci_device.
> > [...]
> >> +/**
> >> + * @internal
> >> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
> >> + */
> >> +static inline struct rte_pci_device *__attribute__((always_inline))
> >> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
> >> +{
> >> + return eth_dev->pci_dev;
> >> +}
> >
> > Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)?
> >
> > I think we must try to avoid any PCI (or other bus) reference inside ethdev.h.
>
> David requested to move it from rte_pci.h to rte_ethdev.h.
>
> It could get forward declared here if one doesn't use it. On the other
> hand the rte_pci.h would be required to include rte_ethdev.h if we
> move it.
I think there is a misunderstanding.
I was just suggesting to drop this function.
On Fri, Dec 23, 2016 at 9:30 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-12-22 19:13, Jan Blunck:
>> On Thu, Dec 22, 2016 at 4:21 PM, Thomas Monjalon
>> <thomas.monjalon@6wind.com> wrote:
>> > 2016-12-21 16:09, Jan Blunck:
>> >> PCI drivers could use this helper instead of directly accessing fields of
>> >> rte_eth_dev to map to rte_pci_device.
>> > [...]
>> >> +/**
>> >> + * @internal
>> >> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
>> >> + */
>> >> +static inline struct rte_pci_device *__attribute__((always_inline))
>> >> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
>> >> +{
>> >> + return eth_dev->pci_dev;
>> >> +}
>> >
>> > Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)?
>> >
>> > I think we must try to avoid any PCI (or other bus) reference inside ethdev.h.
>>
>> David requested to move it from rte_pci.h to rte_ethdev.h.
>>
>> It could get forward declared here if one doesn't use it. On the other
>> hand the rte_pci.h would be required to include rte_ethdev.h if we
>> move it.
>
> I think there is a misunderstanding.
> I was just suggesting to drop this function.
But that would undo the whole purpose of adding a helper. The purpose
of the helper is to map from ethdev to the low-level rte_pci_device.
If we remove this helper all users still need to know how to map to
the embedded device structure. What you ask for also means that the
patch "ethdev: Decouple struct rte_eth_dev from struct rte_pci_device"
needs to change all users of the DEV_PCI_DEV() instead of changing the
helper introduced in this patch.
Let me summarize the workable options from my perspective:
1. helper macro to map from eth_dev to pci_dev in rte_pci.h
2. helper inline function to map from eth_dev to pci_dev in rte_ethdev.h
3. put helpers into new header file rte_ethdrv.h
I'm still in favor of the first option but David suggested to remove
it from eal. I could also counter the type-safety argument from
Stephen by adding a type check to it.
2016-12-23 11:27, Jan Blunck:
> On Fri, Dec 23, 2016 at 9:30 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-12-22 19:13, Jan Blunck:
> >> On Thu, Dec 22, 2016 at 4:21 PM, Thomas Monjalon
> >> <thomas.monjalon@6wind.com> wrote:
> >> > 2016-12-21 16:09, Jan Blunck:
> >> >> PCI drivers could use this helper instead of directly accessing fields of
> >> >> rte_eth_dev to map to rte_pci_device.
> >> > [...]
> >> >> +/**
> >> >> + * @internal
> >> >> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
> >> >> + */
> >> >> +static inline struct rte_pci_device *__attribute__((always_inline))
> >> >> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
> >> >> +{
> >> >> + return eth_dev->pci_dev;
> >> >> +}
> >> >
> >> > Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)?
> >> >
> >> > I think we must try to avoid any PCI (or other bus) reference inside ethdev.h.
> >>
> >> David requested to move it from rte_pci.h to rte_ethdev.h.
> >>
> >> It could get forward declared here if one doesn't use it. On the other
> >> hand the rte_pci.h would be required to include rte_ethdev.h if we
> >> move it.
> >
> > I think there is a misunderstanding.
> > I was just suggesting to drop this function.
>
> But that would undo the whole purpose of adding a helper. The purpose
> of the helper is to map from ethdev to the low-level rte_pci_device.
> If we remove this helper all users still need to know how to map to
> the embedded device structure. What you ask for also means that the
> patch "ethdev: Decouple struct rte_eth_dev from struct rte_pci_device"
> needs to change all users of the DEV_PCI_DEV() instead of changing the
> helper introduced in this patch.
Yes, using RTE_PCI_DEV(eth_dev->device) instead of rte_eth_dev_to_pci(eth_dev).
Is it a problem to know that the field name is "device" to access the
underlying device characteristics?
> Let me summarize the workable options from my perspective:
> 1. helper macro to map from eth_dev to pci_dev in rte_pci.h
> 2. helper inline function to map from eth_dev to pci_dev in rte_ethdev.h
> 3. put helpers into new header file rte_ethdrv.h
>
> I'm still in favor of the first option but David suggested to remove
> it from eal. I could also counter the type-safety argument from
> Stephen by adding a type check to it.
My proposal is:
4. no helper, use eth_dev->device
@@ -1644,6 +1644,16 @@ struct rte_eth_dev {
uint8_t attached; /**< Flag indicating the port is attached */
} __rte_cache_aligned;
+/**
+ * @internal
+ * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device.
+ */
+static inline struct rte_pci_device *__attribute__((always_inline))
+rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev)
+{
+ return eth_dev->pci_dev;
+}
+
struct rte_eth_dev_sriov {
uint8_t active; /**< SRIOV is active with 16, 32 or 64 pools */
uint8_t nb_q_per_pool; /**< rx queue number per pool */