[dpdk-dev] Unlinking hugepage backing file after initialiation

On Mon, Oct 05, 2015 at 01:08:52PM +, Xie, Huawei wrote: > On 9/30/2015 5:36 AM, Michael S. Tsirkin wrote: > > On Tue, Sep 29, 2015 at 05:50:00PM +, shesha Sreenivasamurthy (shesha) > > wrote: > >> Sure. Then, is there any real reason why the backing files should not be > >> unlinked ? >

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > Just forwarding events is not enough to make a valid driver. > What is missing is a way to access the device in a safe way. Thinking about it some more, maybe some devices don't do DMA, and merely signal events with MSI/MSI-X.

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Oct 6, 2015 12:55 AM, "Michael S. Tsirkin" wrote: > > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > > Just forwarding events is not enough to make a valid driver. > > What is missing is a way to access the device in a safe way. > > Thinking about it some more, maybe

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote: > How about instead of trying to invent the wheel just go and attack the problem > directly just like i've proposed already a few times in the last days: instead > of limiting the UIO limit the users that are allowed to use UIO

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

Other than implementation objections, so far the two main arguments against this reduce to: 1. If you allow UIO ioctl then it opens an API hook for all the crap out of tree UIO drivers to do what they want. 2. If you allow UIO MSI-X then you are expanding the usage of userspace

[dpdk-dev] [PATCH v2] devargs: add blacklisting by linux interface name

On Mon, 5 Oct 2015 11:26:08 -0400 Chas Williams <3chas3 at gmail.com> wrote: > diff --git a/lib/librte_eal/common/include/rte_pci.h > b/lib/librte_eal/common/include/rte_pci.h > index 83e3c28..852c149 100644 > --- a/lib/librte_eal/common/include/rte_pci.h > +++

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On 10/06/15 01:49, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote: >> How about instead of trying to invent the wheel just go and attack the >> problem >> directly just like i've proposed already a few times in the last days: >> instead >> of

[dpdk-dev] [PATCH 00/17] Enhance mlx5 with Mellanox OFED 3.1

On Mon, 5 Oct 2015 19:54:35 +0200 Adrien Mazarguil wrote: > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4 > (mlx5) adapters can take advantage of, such as: > > - Separate post and doorbell operations on all queues. > - Lightweight RX queues called Work Queues (WQs). >

[dpdk-dev] [PATCH 00/17] Enhance mlx5 with Mellanox OFED 3.1

Le 6 oct. 2015 09:54, "Stephen Hemminger" a ?crit : > > On Mon, 5 Oct 2015 19:54:35 +0200 > Adrien Mazarguil wrote: > > > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4 > > (mlx5) adapters can take advantage of, such as: > > > > - Separate post and doorbell operations

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On 10/06/2015 10:33 AM, Stephen Hemminger wrote: > Other than implementation objections, so far the two main arguments > against this reduce to: >1. If you allow UIO ioctl then it opens an API hook for all the crap out > of tree UIO drivers to do what they want. >2. If you allow UIO

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Tue, Oct 06, 2015 at 08:33:56AM +0100, Stephen Hemminger wrote: > Other than implementation objections, so far the two main arguments > against this reduce to: > 1. If you allow UIO ioctl then it opens an API hook for all the crap out > of tree UIO drivers to do what they want. > 2. If

[dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API

Hi Marc, On Sun, Oct 04, 2015 at 11:12:46PM +0200, Marc Sune wrote: >[...] > /** > + * Device supported speeds bitmap flags > + */ > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /*< Autonegociate > (all speeds) */ > +#define ETH_LINK_SPEED_NO_AUTONEG(1 << 0) /*< Disable autoneg

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote: > Michael, how this or any other related patch is related to the problem u r > describing? > The above ability is there for years and if memory serves me > well it was u who wrote uio_pci_generic with this "security flaw". ;) I

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote: > btw, (2) doesn't really add any insecurity. The user could already poke at > the msix tables (as well as perform DMA); they just couldn't get a useful > interrupt out of them. Poking at msix tables won't cause memory corruption unless

[dpdk-dev] [PATCH v2] devargs: add blacklisting by linux interface name

On Tue, 2015-10-06 at 08:35 +0100, Stephen Hemminger wrote: > On Mon, 5 Oct 2015 11:26:08 -0400 > Chas Williams <3chas3 at gmail.com> wrote: > > > diff --git a/lib/librte_eal/common/include/rte_pci.h > > b/lib/librte_eal/common/include/rte_pci.h > > index 83e3c28..852c149 100644 > > ---

[dpdk-dev] [PATCH v2 2/4] This patch adds a new UIO driver for Netronome NFP PCI cards.

From: "Alejandro.Lucero" Current Netronome's PMD just supports Virtual Functions. Future Physical Function support will require specific Netronome code here. Signed-off-by: Alejandro.Lucero Signed-off-by: Rolf.Neugebauer ---

[PATCH v2 0/4] Support for Netronome´s NFP-6xxx card

From: "Alejandro.Lucero" This patchset adds a new PMD for Netronome?s NFP-6xxx card along with a new UIO driver, documentation and minor changes to configuration scrips. Alejandro.Lucero (4): This patch adds a PMD driver for Netronome NFP PCI cards. This

[dpdk-dev] [PATCH v2 3/4] This patch adds documentation about Netronome´s NFP nic

From: "Alejandro.Lucero" Signed-off-by: Alejandro.Lucero Signed-off-by: Rolf.Neugebauer --- doc/guides/nics/index.rst |1 + doc/guides/nics/nfp.rst | 270 + 2 files changed, 271 insertions(+) create mode

[dpdk-dev] [PATCH v2 4/4] Modifying configuration scripts for Netronome's nfp_uio driver.

From: "Alejandro.Lucero" Signed-off-by: Alejandro.Lucero Signed-off-by: Rolf.Neugebauer --- tools/dpdk_nic_bind.py |8 ++-- tools/setup.sh | 122 ++-- 2 files changed, 101 insertions(+), 29 deletions(-)

[dpdk-dev] [PATCH v2 1/4] This patch adds a PMD driver for Netronome NFP PCI cards.

From: "Alejandro.Lucero" Signed-off-by: Alejandro.Lucero Signed-off-by: Rolf.Neugebauer --- MAINTAINERS |9 + config/common_linuxapp |6 + doc/guides/rel_notes/release_2_2.rst |8 + drivers/net/Makefile

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On 10/06/15 16:58, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote: >> Michael, how this or any other related patch is related to the problem u r >> describing? >> The above ability is there for years and if memory serves me >> well it was u who wrote

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote: > >and read/write the config space. > >This means that a single userspace bug is enough to corrupt kernel > >memory. > > Could u, pls., provide and example of this simple bug? Because it's > absolutely not obvious... Stick a value

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On 10/06/2015 05:07 PM, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote: >> btw, (2) doesn't really add any insecurity. The user could already poke at >> the msix tables (as well as perform DMA); they just couldn't get a useful >> interrupt out of them. >

[dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X

On 10/06/15 18:00, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote: >>> and read/write the config space. >>> This means that a single userspace bug is enough to corrupt kernel >>> memory. >> Could u, pls., provide and example of this simple bug? Because

[dpdk-dev] Jumbo frame support in pktgen

Hi, Can we generate 9k jumbo frames using the latest pktgen? Thanks! -hs

[dpdk-dev] Jumbo frame support in pktgen

On 10/6/15, 11:07 PM, "dev on behalf of Hyunseok" wrote: >Hi, > >Can we generate 9k jumbo frames using the latest pktgen? Internally I do not create mbufs larger then 2K at this time in Pktgen. I guess it could be changed, but I do not have the time. If you want to submit a patch that would be