From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Jan Blunck <jblunck@infradead.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>, <dev@dpdk.org>,
David Marchand <david.marchand@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v4 21/23] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
Date: Fri, 23 Dec 2016 17:09:28 +0530 [thread overview]
Message-ID: <98a51662-0c77-1b79-2980-8a8dfcf6f100@nxp.com> (raw)
In-Reply-To: <CALe+Z005ByAFq03su4VO_=sH299zS_zAQWjyfyW8jQ3sD7zPrw@mail.gmail.com>
On Friday 23 December 2016 04:57 PM, Jan Blunck wrote:
> On Fri, Dec 23, 2016 at 12:11 PM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> On Friday 23 December 2016 04:20 PM, Jan Blunck wrote:
>>>
>>> On Thu, Dec 22, 2016 at 9:11 AM, Shreyansh Jain <shreyansh.jain@nxp.com>
>>> wrote:
>>>>
>>>> On Thursday 22 December 2016 01:39 AM, Stephen Hemminger wrote:
>>>>>
>>>>>
>>>>> On Wed, 21 Dec 2016 16:09:44 +0100
>>>>> Jan Blunck <jblunck@infradead.org> wrote:
>>>>>
>>>>>> Only the device itself can decide its PCI or not.
>>>>>>
>>>>>> Signed-off-by: Jan Blunck <jblunck@infradead.org>
>>>>>> Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>>>>>> ---
>>>>>
>>>>>
>>>>>
>>>>> I would still like to kill dev_pci from the dev_info API.
>>>>>
>>>
>>> I'm fine with that too.
>>>
>>>>
>>>> +1. It should be rte_dev reference instead.
>>>>
>>>
>>> Only if you can give use-cases for what users should be able to do
>>> with it. If that is the case we need to clearly define what that
>>> means. Do we want to enable users to control the low-level EAL device
>>> directly and shortcut the ethdev driver? If that is necessary we need
>>> to give control to the driver first to decide if it is safe to do so.
>>>
>>
>> An ethernet device is not necessarily a PCI device. With planned removal of
>> rte_pci_device from rte_eth_device, this will be realized.
>> Similarly, the info is also not PCI device specific.
>>
>> With the '+1', my intention was not to say we should do it in this patch. We
>> should prepare eth_dev_info in similar manner as done for pci_dev of
>> rte_eth_dev (ETH_DEV_PCI_DEV() style macro, or inline).
>
> Which is exactly what this patch is doing. I'm moving the filling of
> the PCI information out of the generic code because only the driver
> could know if it is actually handling a PCI device. The generic code
> can not use the ETH_DEV_PCI_DEV() macro in a safe manner.
I fully agree with you and support this series.
Probably I went a step further in my eagerness - I was only hinting that
now info filling part is relatively free of pci-ness, we should remove
eth_dev_info linkage to PCI.
There is no change I am expecting in your patch in this regard. Yours is
the first step to this change.
>
>> And now for whether we should expose lower level device details or not, I
>> was of the view that keeping pci_dev linked to this structure exposes more
>> lower level info than keeping rte_dev. Another view point could be to
>> completely do away with pci_info within eth_dev_info - but, I am not sure of
>> dependencies on it.
>
> If I understand Stephen correctly he questions the benefit of pushing
> down the code to the drivers instead of killing that code completely.
> I'll see what I can do here.
>
Ok. Then I read it wrong. I read it in the sense that we should remove
PCI dependency of eth_info. Except, I considered that removal more as
replacement with rte_device. My mistake!
next prev parent reply other threads:[~2016-12-23 11:35 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-21 15:09 [dpdk-dev] [PATCH v4 00/23] Decouple ethdev from PCI device Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 01/23] eal: define container_of macro Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 02/23] eal: Allow passing const rte_intr_handle Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 03/23] rte_device: make driver pointer const Jan Blunck
2016-12-22 7:18 ` Shreyansh Jain
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 04/23] pmd: remove useless reset of dev_info->dev_pci Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 05/23] e1000: localize mapping from eth_dev to pci Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 06/23] ixgbe: localize mapping from eth_dev to pci_device Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 07/23] i40e: localize mapping of eth_dev to pci Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 08/23] broadcom: localize mapping from " Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 09/23] virtio: Don't fill dev_info->driver_name Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 10/23] virtio: Add vtpci_intr_handle() helper to get rte_intr_handle Jan Blunck
2016-12-21 20:08 ` Stephen Hemminger
2016-12-23 11:04 ` Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 11/23] virtio: Don't depend on struct rte_eth_dev's pci_dev Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 12/23] bnx2x: localize mapping from eth_dev to pci Jan Blunck
2016-12-21 16:35 ` Harish Patil
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 13/23] fm10k: " Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 14/23] qede: localize mapping of " Jan Blunck
2016-12-21 16:35 ` Harish Patil
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 15/23] szedata2: localize handling of pci resources Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 16/23] nfp: localize rte_pci_device handling Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 17/23] vmxnet3: use eth_dev->data->drv_name instead of pci_drv name Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 18/23] ethdev: Helper to map to struct rte_pci_device Jan Blunck
2016-12-22 15:21 ` Thomas Monjalon
2016-12-22 18:13 ` Jan Blunck
2016-12-23 8:30 ` Thomas Monjalon
2016-12-23 10:27 ` Jan Blunck
2016-12-23 12:47 ` Thomas Monjalon
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 19/23] drivers: Replace per-PMD macros with rte_eth_dev_to_pci() helper Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 20/23] drivers: Use " Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 21/23] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get() Jan Blunck
2016-12-21 20:09 ` Stephen Hemminger
2016-12-22 8:11 ` Shreyansh Jain
2016-12-23 10:50 ` Jan Blunck
2016-12-23 11:11 ` Shreyansh Jain
[not found] ` <CALe+Z005ByAFq03su4VO_=sH299zS_zAQWjyfyW8jQ3sD7zPrw@mail.gmail.com>
2016-12-23 11:39 ` Shreyansh Jain [this message]
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 22/23] ethdev: Decouple interrupt handling from PCI device Jan Blunck
2016-12-22 15:13 ` Thomas Monjalon
2016-12-22 18:26 ` Jan Blunck
2016-12-21 15:09 ` [dpdk-dev] [PATCH v4 23/23] ethdev: Decouple struct rte_eth_dev from struct rte_pci_device Jan Blunck
2016-12-22 15:22 ` Thomas Monjalon
2016-12-22 15:26 ` [dpdk-dev] [PATCH v4 00/23] Decouple ethdev from PCI device Thomas Monjalon
2016-12-23 14:28 ` Thomas Monjalon
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 00/20] " Jan Blunck
2016-12-25 22:33 ` Thomas Monjalon
2017-01-03 12:20 ` Ferruh Yigit
2017-01-06 10:07 ` Andrew Rybchenko
2017-01-03 12:24 ` Ferruh Yigit
2017-01-03 14:06 ` Thomas Monjalon
2017-01-03 14:40 ` Ferruh Yigit
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 01/20] eal: define container_of macro Jan Blunck
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 02/20] eal: Allow passing const rte_intr_handle Jan Blunck
2017-01-17 4:42 ` Tan, Jianfeng
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 03/20] rte_device: make driver pointer const Jan Blunck
2016-12-23 16:19 ` Thomas Monjalon
2016-12-23 22:08 ` Stephen Hemminger
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 04/20] pmd: remove useless reset of dev_info->dev_pci Jan Blunck
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 05/20] e1000: localize mapping from eth_dev to pci Jan Blunck
2016-12-23 16:20 ` Thomas Monjalon
2016-12-23 22:06 ` Stephen Hemminger
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 06/20] ixgbe: localize mapping from eth_dev to pci_device Jan Blunck
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 07/20] i40e: localize mapping of eth_dev to pci Jan Blunck
2016-12-23 15:57 ` [dpdk-dev] [PATCH v5 08/20] broadcom: localize mapping from " Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 09/20] virtio: Don't fill dev_info->driver_name Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 10/20] virtio: Add vtpci_intr_handle() helper to get rte_intr_handle Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 11/20] virtio: Don't depend on struct rte_eth_dev's pci_dev Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 12/20] bnx2x: localize mapping from eth_dev to pci Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 13/20] fm10k: " Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 14/20] qede: localize mapping of " Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 15/20] szedata2: localize handling of pci resources Jan Blunck
2016-12-23 18:31 ` Thomas Monjalon
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 16/20] nfp: localize rte_pci_device handling Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 17/20] vmxnet3: use eth_dev->data->drv_name instead of pci_drv name Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 18/20] ethdev: Decouple interrupt handling from PCI device Jan Blunck
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 19/20] ethdev: Move dev_info filling of PCI information into drivers Jan Blunck
2016-12-23 18:45 ` Thomas Monjalon
2016-12-23 15:58 ` [dpdk-dev] [PATCH v5 20/20] ethdev: Decouple from PCI device Jan Blunck
2016-12-23 16:17 ` Thomas Monjalon
2016-12-23 16:20 ` Jan Blunck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98a51662-0c77-1b79-2980-8a8dfcf6f100@nxp.com \
--to=shreyansh.jain@nxp.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=jblunck@infradead.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).