Re: UIO RTE_INTR_MODE_NONE issue.

[Prathap Thammanna <Prathap.Thammanna@radisys.com>]

Yes Stephen, I would be using 
udev->info.irq = UIO_IRQ_NONE;

I will generate a patch and send it out for review.

Thanks for the response.

Regards,
Prathap

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
Sent: 04 July 2015 04:29
To: Prathap T
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] UIO RTE_INTR_MODE_NONE issue.

On Fri, 3 Jul 2015 15:37:40 +0530
Prathap T <prathap.bgl@gmail.com> wrote:

> Hi:
> 
> 
> 
> If INTX fails, igb_uio falls back to running without IRQ ( refer to 
> the implementation in igbuio_pci_probe).
> 
> On QEMU 0.12.0, the INTX seems to have broken, and the intr_mode falls 
> to RTE_INTR_MODE_NONE
> 
> However this sets the udev->info.irq = 0;
> 
> 
> 
> Setting of udev->info.irq  to ‘0’ does not work on *2.6.36 and lower 
> kernels*, because the UIO_IRQ_NONE is defined as
> 
> 
> 
> #define UIO_IRQ_NONE   -2
> 
> 
> 
> Because the udev->info.irq  is set to ‘0’, on *2.6.36 and below* 
> implementation, the *__uio_register_device* invokes request_irq
> 
> 
> 
> if (idev->info->irq >= 0) {
>  ret = request_irq(idev->info->irq, uio_interrupt,
> 
> and it fails with the following dump
> 
> 
> 
> IRQ handler type mismatch for IRQ 0
> 
> current handler: timer
> 
> Pid: 3106, comm: dpdk_nic_bind.p Not tainted 
> 2.6.32-504.23.4.el6.x86_64 #1
> 
> Call Trace:
> 
> [<ffffffff810ebd62>] ? __setup_irq+0x382/0x3c0
> 
> [<ffffffffa033f2a0>] ? uio_interrupt+0x0/0x48 [uio]
> 
> [<ffffffff810ec563>] ? request_threaded_irq+0x133/0x230
> 
> [<ffffffffa033f193>] ? __uio_register_device+0x553/0x610 [uio]
> 
> [<ffffffffa0345652>] ? igbuio_pci_probe+0x3a7/0x4a0 [igb_uio]
> 
> [<ffffffff8128e58a>] ? kobject_get+0x1a/0x30
> 
> [<ffffffff812af417>] ? local_pci_probe+0x17/0x20
> 
> [<ffffffff812b0601>] ? pci_device_probe+0x101/0x120
> 
> [<ffffffff8136c992>] ? driver_sysfs_add+0x62/0x90
> 
> [<ffffffff8136cc2c>] ? driver_probe_device+0x9c/0x3e0
> 
> [<ffffffff8136bd6a>] ? driver_bind+0xca/0x110
> 
> [<ffffffff8136ae3c>] ? drv_attr_store+0x2c/0x30
> 
> [<ffffffff8120a4c5>] ? sysfs_write_file+0xe5/0x170
> 
> [<ffffffff8118e1c8>] ? vfs_write+0xb8/0x1a0
> 
> [<ffffffff8118eb91>] ? sys_write+0x51/0x90
> 
> [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
> 
> igb_uio 0000:00:03.0: PCI INT A disabled
> 
> igb_uio: probe of 0000:00:03.0 failed with error -16
> 
> 
> 
> On kernel *2.6.37* and above, the definition is,
> 
> 
> 
> #define UIO_IRQ_NONE   0
> 
> 
> 
> And the check is,
> 
> 
> 
> if (info->irq && (info->irq != UIO_IRQ_CUSTOM)) {
>                ret = request_irq(info->irq, uio_interrupt,
>                                  info->irq_flags, info->name, idev);
> 
> 
> 
> So to handle the ‘RTE_INTR_MODE_NONE’ in these different kernel 
> versions,
> 
> We are proposing the following change to the code in igbuio_pci_probe 
> function,
> 
> 
> 
> case RTE_INTR_MODE_NONE:
> 
>                 udev->mode = RTE_INTR_MODE_NONE;
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 37)
> 
>          udev->info.irq = -2;
> 
> #else
> 
>         udev->info.irq = 0;
> 
> #endif


Why not use existing UIO_IRQ_NONE which is defined already.

PS: The DPDK needs to get all its drivers upstream. Supporting multiple kernel versions is a long term maintance nightmare. Look at KNI if you want an example of how much of a nuisance this is.

PPS: With DPDK 2.2 it would be good to move the minimum kernel version up to 3.0 since that is what current stable distro's are using.