[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
[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(&pdev->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] 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 ==
&x86_hyper_vmware) {
dev_dbg(&dev->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(&pdev->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
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(&pdev->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 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 ==
> &x86_hyper_vmware) {
> dev_dbg(&dev->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] [PATCH 1/4] add vector PMD RX for FVL
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhe Tao
> Sent: Sunday, September 27, 2015 6:05 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/4] add vector PMD RX for FVL
>
> The vPMD RX function uses the multi-buffer and SSE instructions to
> accelerate the RX speed, but now the pktype cannot be supported by the vPMD
> RX,
> because it will decrease the performance heavily.
>
> Signed-off-by: Zhe Tao
> ---
> config/common_bsdapp | 2 +
> config/common_linuxapp| 2 +
> drivers/net/i40e/Makefile | 1 +
> drivers/net/i40e/base/i40e_type.h | 3 +
> drivers/net/i40e/i40e_rxtx.c | 28 ++-
> drivers/net/i40e/i40e_rxtx.h | 20 +-
> drivers/net/i40e/i40e_rxtx_vec.c | 484
> ++
> 7 files changed, 535 insertions(+), 5 deletions(-)
> create mode 100644 drivers/net/i40e/i40e_rxtx_vec.c
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index b37dcf4..3003da5 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -186,6 +186,8 @@ CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
> CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
> CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
> CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> +CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
> CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 0de43d5..dadba4d 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -184,6 +184,8 @@ CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
> CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
> CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
> CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> +CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
> CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
> index 55b7d31..d4695cb 100644
> --- a/drivers/net/i40e/Makefile
> +++ b/drivers/net/i40e/Makefile
> @@ -95,6 +95,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_dcb.c
>
> SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c
> SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
> +SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec.c
> SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev_vf.c
> SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c
> SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c
> diff --git a/drivers/net/i40e/base/i40e_type.h
> b/drivers/net/i40e/base/i40e_type.h
> index 6ee398e..2720177 100644
> --- a/drivers/net/i40e/base/i40e_type.h
> +++ b/drivers/net/i40e/base/i40e_type.h
> @@ -969,6 +969,9 @@ enum i40e_tx_desc_cmd_bits {
> #define I40E_TXD_QW1_OFFSET_MASK (0x3ULL << \
>I40E_TXD_QW1_OFFSET_SHIFT)
>
> +#define I40E_TD_CMD (I40E_TX_DESC_CMD_ICRC |\
> + I40E_TX_DESC_CMD_EOP)
> +
> enum i40e_tx_desc_length_fields {
> /* Note: These are predefined bit offsets */
> I40E_TX_DESC_LENGTH_MACLEN_SHIFT= 0, /* 7 BITS */
Don't think there is real need to update ND shared code.
You can put that macto in i40e_ethdev.h or i40e_rxtx.h.
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index fd656d5..dfdc7d5 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1788,9 +1788,6 @@ i40e_tx_free_bufs(struct i40e_tx_queue *txq)
> return txq->tx_rs_thresh;
> }
>
> -#define I40E_TD_CMD (I40E_TX_DESC_CMD_ICRC |\
> - I40E_TX_DESC_CMD_EOP)
> -
> /* Populate 4 descriptors with data from 4 mbufs */
> static inline void
> tx4(volatile struct i40e_tx_desc *txdp, struct rte_mbuf **pkts)
> @@ -2625,6 +2622,9 @@ i40e_reset_rx_queue(struct i40e_rx_queue *rxq)
> rxq->nb_rx_hold = 0;
> rxq->pkt_first_seg = NULL;
> rxq->pkt_last_seg = NULL;
> +
> + rxq->rxrearm_start = 0;
> + rxq->rxrearm_nb = 0;
> }
>
> void
> @@ -3063,3 +3063,25 @@ i40e_fdir_setup_rx_resources(struct i40e_pf *pf)
>
> return I40E_SUCCESS;
> }
> +
> +/* Stubs needed for linkage when CONFIG_RTE_I40E_INC_VECTOR is set to 'n' */
> +uint16_t __attribute__((weak))
> +i40e_recv_pkts_vec(
> + void __rte_unused *rx_queue,
> + struct rte_mbuf __rte_unused **rx_pkts,
> + uint16_t __rte_unused nb_pkts)
> +{
> + return 0;
> +}
> +
> +int __attribute__((weak))
> +i40e_rxq_vec_setup(struct i40e_rx_queue __rte_unused *rxq)
> +{
> + return -1;
> +}
> +
> +void __attribute__((weak))
> +i40e_rx_queue_release_mbufs_vec(struct i40e_rx_queue __rte_unused*rxq)
> +{
> + return;
> +}
> diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
> index 4385142..61d9a0e 100644
> --- a/drivers/net/i40e/i40e_rxtx.h
> +++ b/drivers/net/i40e/i40e_rxt
[dpdk-dev] [PATCH] ixgbe: prefetch packet headers in vector PMD receive function
> -Original Message- > From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org] > Sent: Friday, September 25, 2015 7:29 PM > To: Richardson, Bruce; dev at dpdk.org > Cc: Ananyev, Konstantin > Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive > function > > On 07/09/15 07:41, Richardson, Bruce wrote: > > > >> -Original Message- > >> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org] > >> Sent: Monday, September 7, 2015 3:15 PM > >> To: Richardson, Bruce; dev at dpdk.org > >> Cc: Ananyev, Konstantin > >> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive > >> function > >> > >> > >> > >> On 07/09/15 13:57, Richardson, Bruce wrote: > >>> > -Original Message- > From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org] > Sent: Monday, September 7, 2015 1:26 PM > To: dev at dpdk.org > Cc: Ananyev, Konstantin; Richardson, Bruce > Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD > receive function > > Hi, > > I just realized I've missed the "[PATCH]" tag from the subject. Did > anyone had time to review this? > > >>> Hi Zoltan, > >>> > >>> the big thing that concerns me with this is the addition of new > >>> instructions for each packet in the fast path. Ideally, this > >>> prefetching would be better handled in the application itself, as for > >>> some apps, e.g. those using pipelining, the core doing the RX from the > >>> NIC may not touch the packet data at all, and the prefetches will > >> instead cause a performance slowdown. > >>> Is it possible to get the same performance increase - or something > >>> close to it - by making changes in OVS? > >> OVS already does a prefetch when it's processing the previous packet, but > >> apparently it's not early enough. At least for my test scenario, where I'm > >> forwarding UDP packets with the least possible overhead. I guess in tests > >> where OVS does more complex processing it should be fine. > >> I'll try to move the prefetch earlier in OVS codebase, but I'm not sure if > >> it'll help. > > I would suggest trying to prefetch more than one packet ahead. Prefetching > > 4 or > > 8 ahead might work better, depending on the processing being done. > > I've moved the prefetch earlier, and it seems to work: > > https://patchwork.ozlabs.org/patch/519017/ > > However it raises the question: should we remove header prefetch from > all the other drivers, and the CONFIG_RTE_PMD_PACKET_PREFETCH option? My vote would be for that. Konstantin > > > > > /Bruce
[dpdk-dev] GPL/LGPL .vs BSD license
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 # 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] 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 >
