From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Guo, Jia" <jia.guo@intel.com>,
jianfeng.tan@intel.com, jingjing.wu@intel.com,
thomas@monjalon.net
Cc: dev@dpdk.org, helin.zhang@intel.com
Subject: Re: [dpdk-dev] [PATCH V2] igb_uio: fix uevent montior issue
Date: Tue, 27 Mar 2018 18:10:36 +0100 [thread overview]
Message-ID: <f696ad31-8992-7e3c-c106-bddf13258325@intel.com> (raw)
In-Reply-To: <58a0257a-b0a7-1895-7d7a-f5b623681d82@intel.com>
On 3/27/2018 8:46 AM, Guo, Jia wrote:
>
>
> On 3/27/2018 2:28 AM, Ferruh Yigit wrote:
>> On 2/27/2018 7:20 AM, Jeff Guo wrote:
>>> udev could not detect remove and add event of device when hotplug in
>>> and out devices, that related with the fix about using pointer of
>>> rte_uio_pci_dev as dev_id instead of uio_device for irq device handler,
>>> that would result igb uio irq failure when kernel version after than 3.17.
>>>
>>> The root cause is that the older version of Linux kernel don't expose the
>>> uio_device structure, only for the kernel version after than 3.17 use
>>> uio_device. so this patch correct it by use a macro to check before handle
>>> the pci interrupt.
>>>
>>> Fixes: 6b9ed026a870 ("igb_uio: fix build with kernel <= 3.17")
>>> Signed-off-by: Jeff Guo <jia.guo@intel.com>
>>> ---
>>> v2->v1:
>>> use macro in compat.h to replace of version check in .c file, benifit for
>>> future backport and make more readable.
>>> ---
>>> lib/librte_eal/linuxapp/igb_uio/compat.h | 4 ++++
>>> lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 16 ++++++++++++++++
>>> 2 files changed, 20 insertions(+)
>>>
>>> diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h b/lib/librte_eal/linuxapp/igb_uio/compat.h
>>> index ce456d4..2c61190 100644
>>> --- a/lib/librte_eal/linuxapp/igb_uio/compat.h
>>> +++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
>>> @@ -132,3 +132,7 @@ static bool pci_check_and_mask_intx(struct pci_dev *pdev)
>>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 5, 0)
>>> #define HAVE_PCI_MSI_MASK_IRQ 1
>>> #endif
>>> +
>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(3, 17, 0)
>>> +#define HAVE_UIO_DEVICE_STRUCTURE 1
>>> +#endif
>>> diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> index 4cae4dd..99018f4 100644
>>> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>>> @@ -192,8 +192,14 @@ igbuio_pci_irqcontrol(struct uio_info *info, s32 irq_state)
>>> static irqreturn_t
>>> igbuio_pci_irqhandler(int irq, void *dev_id)
>>> {
>>> +#ifndef HAVE_UIO_DEVICE_STRUCTURE
>>> struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id;
>>> struct uio_info *info = &udev->info;
>>> +#else
>>> + struct uio_device *idev = (struct uio_device *)dev_id;
>>> + struct uio_info *info = idev->info;
>>> + struct rte_uio_pci_dev *udev = info->priv;
>>> +#endif
>>>
>>> /* Legacy mode need to mask in hardware */
>>> if (udev->mode == RTE_INTR_MODE_LEGACY &&
>>> @@ -279,9 +285,15 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
>>> }
>>>
>>> if (udev->info.irq != UIO_IRQ_NONE)
>>> +#ifndef HAVE_UIO_DEVICE_STRUCTURE
>>> err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
>>> udev->info.irq_flags, udev->info.name,
>>> udev);
>>> +#else
>>> + err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
>>> + udev->info.irq_flags, udev->info.name,
>>> + udev->info.uio_dev);
>>> +#endif
>> Hi Jeff,
>>
>> Can you please describe how this is solving the problem. Isn't only requirement
>> for dev_id to be unique? Why it differs to pass uio_dev instead of udev pointer?
>
> Hi, ferruh
>
>
> yes, this is because the uio_device definition is not exposed in kernel earlier
> than 3.17, you could check the history of commit
> (6b9ed026a8704b9e5ee5da7997617ef7cc82e114), igb_uio: fix build with kernel <=
> 3.17, which fix it by
I get this part.
The question is how this is fixing uevent monitor issue.
Isn't the last parameter of the request_irq() is "void *" that has been passed
to handler.
Why and where it differs if that pointer is "struct uio_device" or not?
>
> use using pointer of rte_uio_pci_dev instead.
>
>>> dev_info(&udev->pdev->dev, "uio device registered with irq %ld\n",
>>> udev->info.irq);
>>>
>>> @@ -292,7 +304,11 @@ static void
>>> igbuio_pci_disable_interrupts(struct rte_uio_pci_dev *udev)
>>> {
>>> if (udev->info.irq) {
>>> +#ifndef HAVE_UIO_DEVICE_STRUCTURE
>>> free_irq(udev->info.irq, udev);
>>> +#else
>>> + free_irq(udev->info.irq, udev->info.uio_dev);
>>> +#endif
>>> udev->info.irq = 0;
>>> }
>>>
>>>
>
prev parent reply other threads:[~2018-03-27 17:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 10:01 [dpdk-dev] [PATCH] " Jeff Guo
2018-01-31 2:15 ` Wu, Jingjing
2018-02-08 22:01 ` Thomas Monjalon
2018-02-12 8:28 ` Guo, Jia
2018-02-12 9:46 ` Thomas Monjalon
2018-02-13 9:32 ` Ferruh Yigit
2018-02-27 6:17 ` Guo, Jia
2018-02-27 7:20 ` [dpdk-dev] [PATCH V2] " Jeff Guo
2018-03-26 18:28 ` Ferruh Yigit
2018-03-27 7:46 ` Guo, Jia
2018-03-27 17:10 ` Ferruh Yigit [this message]
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=f696ad31-8992-7e3c-c106-bddf13258325@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jia.guo@intel.com \
--cc=jianfeng.tan@intel.com \
--cc=jingjing.wu@intel.com \
--cc=thomas@monjalon.net \
/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).