[dpdk-dev] GPL/LGPL .vs BSD license
On Sun, 27 Sep 2015 20:44:41 -0500 Jim Thompson wrote: > The following files have LGPL or GPL licenses. I can see the libretto_eal > and the four files that are part of DTS being GPL, but there others seem like > a mistake. > Especially the docs, and the presence of the LICENSE.LGPL file. > > Is it possible to clean these up and make them BSD licensed? > > Jim No. KNI, Xen, and IGB UIO must be GPL licensed since they are kernel drivers. The other stuff header files should be dual licensed. > # QEMU Guest Agent Client > ./dts/dep/QMP/qemu-ga-client > ./dts/dep/QMP/qmp.py > > Came from Scapy > ./dts/dep/lldp.py > > Texttable Framework (LGPL) > ./dts/framework/texttable.py > > These are part of DPDK proper: > ./dpdk/LICENSE.LGPL > ./dpdk/app/test/test_mempool.c > ./dpdk/doc/guides/freebsd_gsg/build_dpdk.rst > ./dpdk/doc/guides/linux_gsg/build_dpdk.rst > ./dpdk/doc/guides/nics/mlx4.rst > ./dpdk/doc/guides/sample_app_ug/img/l2_fwd_virtenv_benchmark_setup.png > ./dpdk/lib/librte_eal/bsdapp/eal/include/exec-env/rte_dom0_common.h > ./dpdk/lib/librte_eal/common/include/rte_pci_dev_feature_defs.h > ./dpdk/lib/librte_eal/common/include/rte_pci_dev_features.h > ./dpdk/lib/librte_eal/common/include/rte_pci_dev_ids.h > ./dpdk/lib/librte_eal/linuxapp/eal/include/exec-env/rte_dom0_common.h > ./dpdk/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > ./dpdk/lib/librte_eal/linuxapp/igb_uio/igb_uio.c > ./dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING > ./dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c > ./dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat_ethtool.c > ./dpdk/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/COPYING > ./dpdk/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c > ./dpdk/lib/librte_eal/linuxapp/kni/kni_dev.h > ./dpdk/lib/librte_eal/linuxapp/kni/kni_ethtool.c > ./dpdk/lib/librte_eal/linuxapp/kni/kni_fifo.h > ./dpdk/lib/librte_eal/linuxapp/kni/kni_misc.c > ./dpdk/lib/librte_eal/linuxapp/kni/kni_net.c > ./dpdk/lib/librte_eal/linuxapp/kni/kni_vhost.c > ./dpdk/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_dev.h > ./dpdk/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c > ./dpdk/lib/librte_vhost/eventfd_link/eventfd_link.c > ./dpdk/lib/librte_vhost/eventfd_link/eventfd_link.h > ./dpdk/pkg/dpdk.spec >
[dpdk-dev] [PATCH 4/4 v2] vhost: fix wrong usage of eventfd_t
2015-09-27 08:17, Yuanhan Liu: > On Fri, Sep 25, 2015 at 02:44:11PM +0200, Thomas Monjalon wrote: > > - make the first email the child of the previous version > > I'm wondering how could you do that, with git-send-email. It can be checked in http://dpdk.org/dev#send: --in-reply-to The message id is in the mail headers.
[dpdk-dev] [PATCH] Fix VMware emulated e1000 doesn't support INTX_DISABLE flag
On Sun, 27 Sep 2015 12:51:06 +0400
"Kirill A. Korinsky" wrote:
> When you try to run any DPDK-app in VMWare with e1000/82545EM NIC
> you have a lot of lines like:
>
> EAL: Error reading from file descriptor 9: Input/output error
>
> The reason of this error is bad INTX emulation in VMWare
> and pci_intx_mask_supported return false every time.
> ---
> lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> index 865a276..c85f7e5 100644
> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> @@ -36,6 +36,7 @@
> #ifdef CONFIG_XEN_DOM0
> #include
> #endif
> +#include
> #include
>
> #include "compat.h"
> @@ -508,7 +509,8 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> }
> /* fall back to INTX */
> case RTE_INTR_MODE_LEGACY:
> - if (pci_intx_mask_supported(dev)) {
> + /* VMware emulated e1000 doesn't support INTX_DISABLE flag */
> + if (pci_intx_mask_supported(dev) || x86_hyper ==
> _hyper_vmware) {
> dev_dbg(>dev, "using INTX");
> udev->info.irq_flags = IRQF_SHARED;
> udev->info.irq = dev->irq;
I don't think driver should be expecting INTx to work on VMware.
If kernel test fails, it means masking is broken (in VMware).
It is better for driver (E1000 PMD) to report that Link state interrupt does
not work (if IRQ setup fails). Then application can test if LSC irq works
and not enable it.
[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance
On Sep 27, 2015 12:43 PM, "Michael S. Tsirkin" wrote:
>
> On Sun, Sep 27, 2015 at 10:05:11AM +0300, Vlad Zolotarov wrote:
> > Hi,
> > I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
> > Amazon EC2 instances with Enhanced Networking enabled.
> > The idea is to create a DPDK environment that doesn't require compiling
> > kernel modules (igb_uio).
> > However I was surprised to discover that uio_pci_generic refuses to work
> > with EN device on AWS:
> >
> > $ lspci
> > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma]
(rev 02)
> > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton
II]
> > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II]
> > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> > 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> > 00:03.0 Ethernet controller: Intel Corporation 82599 Ethernet
Controller Virtual Function (rev 01)
> > 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet
Controller Virtual Function (rev 01)
> > 00:1f.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device
(rev 01)
> >
> > $ sudo ./dpdk/tools/dpdk_nic_bind.py -b uio_pci_generic 00:04.0
> > Error: bind failed for :00:04.0 - Cannot bind to driver
uio_pci_generic
>
> > $dmesg
> >
> > --> snip <---
> > [ 816.655575] uio_pci_generic :00:04.0: No IRQ assigned to device:
no support for interrupts?
> >
> > $ sudo lspci -s 00:04.0 -vvv
> > 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet
Controller Virtual Function (rev 01)
> > Physical Slot: 4
> > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- > Region 0: Memory at f3008000 (64-bit, prefetchable) [size=16K]
> > Region 3: Memory at f300c000 (64-bit, prefetchable) [size=16K]
> > Capabilities: [70] MSI-X: Enable- Count=3 Masked-
> > Vector table: BAR=3 offset=
> > PBA: BAR=3 offset=2000
> > Kernel modules: ixgbevf
> >
> > So, as we may see the PCI device doesn't have an INTX interrupt line
> > assigned indeed. It has an MSI-X capability however.
> > Looking at the uio_pci_generic code it seems to require the INTX:
> >
> > uio_pci_generic.c: line 74: probe():
> >
> > if (!pdev->irq) {
> > dev_warn(>dev, "No IRQ assigned to device: "
> >"no support for interrupts?\n");
> > pci_disable_device(pdev);
> > return -ENODEV;
> > }
> >
> > Is it a known limitation? Michael, could u, pls., comment on this?
> >
> > thanks,
> > vlad
>
> This is expected. uio_pci_generic forwards INT#x interrupts from device
> to userspace, but VF devices never assert INT#x.
>
> So it doesn't seem to make any sense to bind uio_pci_generic there.
>
> I think that DPDK should be fixed to not require uio_pci_generic
> for VF devices (or any devices without INT#x).
>
> If DPDK requires a place-holder driver, the pci-stub driver should
> do this adequately. See ./drivers/pci/pci-stub.c
Thank for clarification, Michael. I'll take a look.
>
> --
> MST
[dpdk-dev] [PATCH] Fix VMware emulated e1000 doesn't support INTX_DISABLE flag
When you try to run any DPDK-app in VMWare with e1000/82545EM NIC
you have a lot of lines like:
EAL: Error reading from file descriptor 9: Input/output error
The reason of this error is bad INTX emulation in VMWare
and pci_intx_mask_supported return false every time.
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 865a276..c85f7e5 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -36,6 +36,7 @@
#ifdef CONFIG_XEN_DOM0
#include
#endif
+#include
#include
#include "compat.h"
@@ -508,7 +509,8 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
}
/* fall back to INTX */
case RTE_INTR_MODE_LEGACY:
- if (pci_intx_mask_supported(dev)) {
+ /* VMware emulated e1000 doesn't support INTX_DISABLE flag */
+ if (pci_intx_mask_supported(dev) || x86_hyper ==
_hyper_vmware) {
dev_dbg(>dev, "using INTX");
udev->info.irq_flags = IRQF_SHARED;
udev->info.irq = dev->irq;
--
2.5.3
[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance
On Sun, Sep 27, 2015 at 10:05:11AM +0300, Vlad Zolotarov wrote:
> Hi,
> I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
> Amazon EC2 instances with Enhanced Networking enabled.
> The idea is to create a DPDK environment that doesn't require compiling
> kernel modules (igb_uio).
> However I was surprised to discover that uio_pci_generic refuses to work
> with EN device on AWS:
>
> $ lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:03.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 00:1f.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> $ sudo ./dpdk/tools/dpdk_nic_bind.py -b uio_pci_generic 00:04.0
> Error: bind failed for :00:04.0 - Cannot bind to driver uio_pci_generic
> $dmesg
>
> --> snip <---
> [ 816.655575] uio_pci_generic :00:04.0: No IRQ assigned to device: no
> support for interrupts?
>
> $ sudo lspci -s 00:04.0 -vvv
> 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> Physical Slot: 4
> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Region 0: Memory at f3008000 (64-bit, prefetchable) [size=16K]
> Region 3: Memory at f300c000 (64-bit, prefetchable) [size=16K]
> Capabilities: [70] MSI-X: Enable- Count=3 Masked-
> Vector table: BAR=3 offset=
> PBA: BAR=3 offset=2000
> Kernel modules: ixgbevf
>
> So, as we may see the PCI device doesn't have an INTX interrupt line
> assigned indeed. It has an MSI-X capability however.
> Looking at the uio_pci_generic code it seems to require the INTX:
>
> uio_pci_generic.c: line 74: probe():
>
> if (!pdev->irq) {
> dev_warn(>dev, "No IRQ assigned to device: "
>"no support for interrupts?\n");
> pci_disable_device(pdev);
> return -ENODEV;
> }
>
> Is it a known limitation? Michael, could u, pls., comment on this?
>
> thanks,
> vlad
This is expected. uio_pci_generic forwards INT#x interrupts from device
to userspace, but VF devices never assert INT#x.
So it doesn't seem to make any sense to bind uio_pci_generic there.
I think that DPDK should be fixed to not require uio_pci_generic
for VF devices (or any devices without INT#x).
If DPDK requires a place-holder driver, the pci-stub driver should
do this adequately. See ./drivers/pci/pci-stub.c
--
MST
[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance
Hi,
I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
Amazon EC2 instances with Enhanced Networking enabled.
The idea is to create a DPDK environment that doesn't require compiling
kernel modules (igb_uio).
However I was surprised to discover that uio_pci_generic refuses to work
with EN device on AWS:
$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
00:1f.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
$ sudo ./dpdk/tools/dpdk_nic_bind.py -b uio_pci_generic 00:04.0
Error: bind failed for :00:04.0 - Cannot bind to driver uio_pci_generic
$dmesg
--> snip <---
[ 816.655575] uio_pci_generic :00:04.0: No IRQ assigned to device: no
support for interrupts?
$ sudo lspci -s 00:04.0 -vvv
00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
Physical Slot: 4
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- irq) {
dev_warn(>dev, "No IRQ assigned to device: "
"no support for interrupts?\n");
pci_disable_device(pdev);
return -ENODEV;
}
Is it a known limitation? Michael, could u, pls., comment on this?
thanks,
vlad
[dpdk-dev] [PATCH 4/4 v2] vhost: fix wrong usage of eventfd_t
On Fri, Sep 25, 2015 at 02:44:11PM +0200, Thomas Monjalon wrote: > 2015-09-24 22:01, Yuanhan Liu: > > Would you consider to apply these 4 patches please? The 4th patch > > affects quite many lines of code, and the sooner we apply it, the > > fewer chance it will introduce conflicts for later patches. > > Yes, I'm checking it. > > The patch 4/4 is v2. Other ones have no version. Which means no changes for others in this version. > When you'll send a new version of a new patchset, please > - increment version number of every patches to the same number And, I can do that. > - make the first email the child of the previous version I'm wondering how could you do that, with git-send-email. --yliu
