[dpdk-dev] How kernel can share the mem from dpdk hugepage?

Hi all, I want to ask does anybody know how kernel can share the info from dpdk hugepage. My project has a requirement which kernel needs to get some info from dpdk application. Eg, in multi-process example, every client has a shared ring buffer with server. The shared ring contains some meta

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

On Thu, Oct 01, 2015 at 10:26:19AM -0700, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 19:31:08 +0300 > "Michael S. Tsirkin" wrote: > > > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > > > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > > > This driv

[dpdk-dev] [PATCHv5 8/8] testpmd: add new command to display RX/TX queue information

From: "Ananyev, Konstantin" Signed-off-by: Konstantin Ananyev --- app/test-pmd/cmdline.c | 48 +++ app/test-pmd/config.c | 77 ++ app/test-pmd/testpmd.h | 2 ++ 3 files changed, 127 insertions(+) diff --git a/app/tes

[dpdk-dev] [PATCHv5 7/8] vmxnet3: add HW specific desc_lim data into dev_info

Signed-off-by: Konstantin Ananyev --- drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c index a70be5c..3745b7d 100644 --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c +++ b/

[dpdk-dev] [PATCHv5 6/8] cxgbe: add HW specific desc_lim data into dev_info

Signed-off-by: Konstantin Ananyev --- drivers/net/cxgbe/cxgbe_ethdev.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c index 478051a..6d26899 100644 --- a/drivers/net/cxgbe/cxgbe_ethdev.c +++ b/drivers/net/cxgbe/cxgb

[dpdk-dev] [PATCHv5 5/8] fm10k: add HW specific desc_lim data into dev_info

Signed-off-by: Konstantin Ananyev --- drivers/net/fm10k/fm10k_ethdev.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c index a69c990..9588dab 100644 --- a/drivers/net/fm10k/fm10k_ethdev.c +++ b/drivers/net/fm10k/

[dpdk-dev] [PATCHv5 4/8] e1000: add support for eth_(rxq|txq)_info_get and (rx|tx)_desc_lim

From: "Ananyev, Konstantin" Signed-off-by: Konstantin Ananyev --- drivers/net/e1000/e1000_ethdev.h | 36 drivers/net/e1000/em_ethdev.c| 14 drivers/net/e1000/em_rxtx.c | 71 +++- drivers/net/e1000/igb_ethdev.c | 22 +++

[dpdk-dev] [PATCHv5 3/8] ixgbe: add support for eth_(rxq|txq)_info_get and (rx|tx)_desc_lim

From: "Ananyev, Konstantin" Signed-off-by: Konstantin Ananyev --- drivers/net/ixgbe/ixgbe_ethdev.c | 23 ++ drivers/net/ixgbe/ixgbe_ethdev.h | 6 drivers/net/ixgbe/ixgbe_rxtx.c | 68 +--- drivers/net/ixgbe/ixgbe_rxtx.h | 21 +

[dpdk-dev] [PATCHv5 2/8] i40e: add support for eth_(rxq|txq)_info_get and (rx|tx)_desc_lim

From: "Ananyev, Konstantin" This patch assumes that the patch: i40e: fix wrong alignment for the number of HW descriptors already applied. Signed-off-by: Konstantin Ananyev --- drivers/net/i40e/i40e_ethdev.c| 14 ++ drivers/net/i40e/i40e_ethdev.h| 5 + drivers/net/i40e

[dpdk-dev] [PATCHv5 1/8] ethdev: add new API to retrieve RX/TX queue information

From: "Ananyev, Konstantin" Add the ability for the upper layer to query RX/TX queue information. Add into rte_eth_dev_info new fields to represent information about RX/TX descriptors min/max/alig nnumbers per queue for the device. Add new structures: struct rte_eth_rxq_info struct rte_eth_txq_i

[dpdk-dev] [PATCHv5 0/8] ethdev: add new API to retrieve RX/TX queue information

Add the ability for the upper layer to query: 1) configured RX/TX queue information. 2) information about RX/TX descriptors min/max/align numbers per queue for the device. Right now 1) is implemented for: ixgbe, i40e, e1000 PMDs. Ananyev, Konstantin (5): ethdev: add new API to retrieve RX/TX qu

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

On 10/01/2015 05:04 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 16:40:10 -0700 > Alexander Duyck wrote: > >> Do you really need to map IORESOURCE bars? Most drivers I can think of >> don't use IO BARs anymore. Maybe we could look at just dropping the >> code and adding it back later if we

[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: > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > This driver allows using PCI device with Message Signalled Interrupt > > from userspace. The API is similar to the igb_uio driver used by the DPDK. > > Via io

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

On Thu, Oct 01, 2015 at 01:37:12PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > > This driver allows using PCI device with Message Signalled Interrupt > > > from user

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 04:14:33PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote: > > > > This in itself is going to use up > > > > a good proportion of the processing time, as well as that we have to > > > > spend cycles > > > > copying the de

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 11:42:23AM +0200, Vincent JARDIN wrote: > There were some tentative to get it for other (older) drivers, named > 'bifurcated drivers', but it is stalled. That approach also has the advantage that userspace bugs can't do silly things like reprogram device's EEPROM by mistake

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 07:55:20AM -0700, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 13:14:08 +0300 > "Michael S. Tsirkin" wrote: > > > On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote: > > > >There were some tentative to get it for other (older) drivers, named > > > >'bifurcated dri

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 08:01:00AM -0700, Stephen Hemminger wrote: > The per-driver ring method is what netmap did. IIUC netmap has a standard format for descriptors, so was slower: it still had to do all networking in kernel (it only bypasses part of the networking stack), and to have a thread to

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 06:19:33PM +0300, Avi Kivity wrote: > On 10/01/2015 06:11 PM, Michael S. Tsirkin wrote: > >On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote: > >>> We already agreed this kernel > >>>is going to be tainted, and unsupportable. > >>Yes. So your only motivation in re

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 05:04 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 16:43:23 -0700 > Alexander Duyck wrote: > >> Yes, but in the case of something like a VF it is going to just make a >> bigger mess of things since INTx doesn't work. So what would you expect >> your driver to do in that case?

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

On Thu, Oct 01, 2015 at 07:50:37AM -0700, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 11:33:06 +0300 > "Michael S. Tsirkin" wrote: > > > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > > This driver allows using PCI device with Message Signalled Interrupt > > > from users

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

On 10/01/2015 05:01 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 16:40:10 -0700 > Alexander Duyck wrote: > >> I agree with some other reviewers. Why call pci_enable_msix in open? >> It seems like it would make much more sense to do this on probe, and >> then disable MSI-X on free. I can onl

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 06:11 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote: >>> We already agreed this kernel >>> is going to be tainted, and unsupportable. >> Yes. So your only motivation in rejecting the patch is to get the author to >> write the ring transl

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote: > > We already agreed this kernel > >is going to be tainted, and unsupportable. > > Yes. So your only motivation in rejecting the patch is to get the author to > write the ring translation patch and port it to all relevant drivers > ins

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 06:01 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 14:32:19 +0300 > Avi Kivity wrote: > >> On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote: >>> On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: People will just use out of tree drivers (dpdk has several already).

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/15 17:47, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 11:00:28 +0300 > Vlad Zolotarov wrote: > >> >> On 10/01/15 00:36, Stephen Hemminger wrote: >>> On Wed, 30 Sep 2015 23:09:33 +0300 >>> Vlad Zolotarov wrote: >>> On 09/30/15 22:39, Michael S. Tsirkin wrote: > On Wed, Sep 30

[dpdk-dev] virtio-net: bind systematically on all non blacklisted virtio-net devices

2015-09-10 14:30, Franck Baudin: > On 09/09/15 04:11, Ouyang, Changchun wrote: > >> virtio-net driver bind on all virtio-net devices, even if the devices are > >> used by > >> the kernel (leading to kernel soft-lookup/panic). One way around is to > >> blacklist the ports in use by Linux. This is t

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

On Thu, 1 Oct 2015 16:40:10 -0700 Alexander Duyck wrote: > Do you really need to map IORESOURCE bars? Most drivers I can think of > don't use IO BARs anymore. Maybe we could look at just dropping the > code and adding it back later if we have a use case that absolutely > needs it. Mapping is

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 16:43:23 -0700 Alexander Duyck wrote: > Yes, but in the case of something like a VF it is going to just make a > bigger mess of things since INTx doesn't work. So what would you expect > your driver to do in that case? Also we have to keep in mind that the > MSI-X failure

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

On Thu, 1 Oct 2015 16:40:10 -0700 Alexander Duyck wrote: > I agree with some other reviewers. Why call pci_enable_msix in open? > It seems like it would make much more sense to do this on probe, and > then disable MSI-X on free. I can only assume you are trying to do it > to save on resource

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 04:39 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 16:03:06 -0700 > Alexander Duyck wrote: > >> On 10/01/2015 03:00 PM, Stephen Hemminger wrote: >>> On Thu, 1 Oct 2015 12:48:36 -0700 >>> Alexander Duyck wrote: >>> On 10/01/2015 07:57 AM, Stephen Hemminger wrote: > On T

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

On 09/30/2015 03:28 PM, Stephen Hemminger wrote: > This driver allows using PCI device with Message Signalled Interrupt > from userspace. The API is similar to the igb_uio driver used by the DPDK. > Via ioctl it provides a mechanism to map MSI-X interrupts into event > file descriptors similar to V

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 16:03:06 -0700 Alexander Duyck wrote: > On 10/01/2015 03:00 PM, Stephen Hemminger wrote: > > On Thu, 1 Oct 2015 12:48:36 -0700 > > Alexander Duyck wrote: > > > >> On 10/01/2015 07:57 AM, Stephen Hemminger wrote: > >>> On Thu, 1 Oct 2015 13:59:02 +0300 > >>> Avi Kivity wrote:

[dpdk-dev] [PATCH] crc: deinline crc functions

Because the CRC functions are inline and defined purely in the header file, every component that uses these functions gets its own copy of the software CRC table which is a big space waster. Just deinline which give better long term ABI stablity anyway. Signed-off-by: Stephen Hemminger --- app/

[dpdk-dev] [PATCH] doc: fix rst issues in testpmd user guide

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara > Sent: Monday, September 28, 2015 8:46 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: fix rst issues in testpmd user guide > > Fix a number of RST issues in the testpmd user guide a

[dpdk-dev] [PATCH 1/1] vmxnet3: add PCI Port Hotplug support

Signed-off-by: Bernard Iremonger --- drivers/net/vmxnet3/vmxnet3_ethdev.c | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c index 2beee3e..5cd708e 100644 --- a/drivers

[dpdk-dev] [PATCH 0/1] vmxnet3 hotplug support

add PCI Port Hotplug support to the vmxnet3 PMD This patch depends on 4 patches from the following patch set: -remove-pci-driver-from-vdevs.patch 0001-librte_eal-add-RTE_KDRV_NONE-for-vdevs.patch 0002-librte_ether-add-fields-from-rte_pci_driver-to-rte_e.patch 0003-librte_ether-add-function

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote: > > > This in itself is going to use up > > > a good proportion of the processing time, as well as that we have to > > > spend cycles > > > copying the descriptors from one ring in memory to another. Given that > > > right now > >

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 03:00 PM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 12:48:36 -0700 > Alexander Duyck wrote: > >> On 10/01/2015 07:57 AM, Stephen Hemminger wrote: >>> On Thu, 1 Oct 2015 13:59:02 +0300 >>> Avi Kivity wrote: >>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote: > This is a

[dpdk-dev] DPDK Logo Release

When can we expect the main website (including home page http://dpdk.org/) to be updated? Have we opened up the website to allow the community to edit it? (I think this has been discussed in the past...) Who owns website changes today? -Original Message- From: dev [mailto:dev-boun...@dpd

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 12:48:36 -0700 Alexander Duyck wrote: > On 10/01/2015 07:57 AM, Stephen Hemminger wrote: > > On Thu, 1 Oct 2015 13:59:02 +0300 > > Avi Kivity wrote: > > > >> On 10/01/2015 01:28 AM, Stephen Hemminger wrote: > >>> This is a new UIO device driver to allow supporting MSI-X and MS

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 02:31 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: >> >> On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote: >>> On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: >> It's not just the lack of system calls, of course, the arc

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: >> People will just use out of tree drivers (dpdk has several already). It's a >> pain, but nowhere near what you are proposing. > What's the issue with that? Out of tree drivers have t

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: > > > On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote: > >On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: > It's not just the lack of system calls, of course, the architecture is > completely different. > >>>Absolute

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: > People will just use out of tree drivers (dpdk has several already). It's a > pain, but nowhere near what you are proposing. What's the issue with that? We already agreed this kernel is going to be tainted, and unsupportable.

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:08:07PM +0100, Bruce Richardson wrote: > On Thu, Oct 01, 2015 at 01:38:37PM +0300, Michael S. Tsirkin wrote: > > On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote: > > > > > > > > > On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote: > > > >On Thu, Oct 01, 2015 a

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: It's not just the lack of system calls, of course, the architecture is completely different. >>> Absolutely - I'm not saying move all of DPDK into kernel. >>> We just need to

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 02:42 AM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: >> even when they are some users >> prefer to avoid the performance penalty. > I don't think there's a measureable penalty from passing through the > IOMMU, as long as mappings are mostly

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: > > > >>It's not just the lack of system calls, of course, the architecture is > >>completely different. > >Absolutely - I'm not saying move all of DPDK into kernel. > >We just need to protect the RX rings so hardware does > >not corrupt k

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 06:14 AM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote: This in itself is going to use up a good proportion of the processing time, as well as that we have to spend cycles copying the descriptors from one ring in mem

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 01:28 AM, Stephen Hemminger wrote: > This is a new UIO device driver to allow supporting MSI-X and MSI devices > in userspace. It has been used in environments like VMware and older versions > of QEMU/KVM where no IOMMU support is available. Why not add msi/msix support to uio_pci_g

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:44 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 01:25:17PM +0300, Avi Kivity wrote: >> Why use a VF on a non-virtualized system? > 1. So a userspace bug does not destroy your hardware > (PFs generally assume trusted non-buggy drivers, VFs > generally don't).

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:38 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote: >> >> On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote: >>> On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: It's easy to claim that a solution is around the corner

[dpdk-dev] DPDK Logo Release

We'd like to announce the release of the new DPDK project logo. Various versions of the logo are available at: http://dpdk.org/about. This includes horizontal and vertical versions, versions with and without Data Plane Development Kit underneath, and versions suitable for a white or black backg

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 01:25:17PM +0300, Avi Kivity wrote: > Why use a VF on a non-virtualized system? 1. So a userspace bug does not destroy your hardware (PFs generally assume trusted non-buggy drivers, VFs generally don't). 2. So you can use a PF or another VF for regular networking. 3.

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote: > > > On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote: > >On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: > >>It's easy to claim that > >>a solution is around the corner, only no one was looking for it, but the > >>reality i

[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: > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > This driver allows using PCI device with Message Signalled Interrupt > > from userspace. The API is similar to the igb_uio driver used by the DPDK. > > Via io

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:24 PM, Avi Kivity wrote: > On 10/01/2015 01:17 PM, Michael S. Tsirkin wrote: >> On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote: >>> Non-virtualized setups have an iommu available, but they can also use >>> pci_uio_generic without patching if they like. >> Not with VFs

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:17 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote: >> Non-virtualized setups have an iommu available, but they can also use >> pci_uio_generic without patching if they like. > Not with VFs, they can't. > They can and they do (I use it my

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:14 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote: >>> There were some tentative to get it for other (older) drivers, named >>> 'bifurcated drivers', but it is stalled. >> IIRC they still exposed the ring to userspace. > How much would

[dpdk-dev] [PATCH v2] ip_pipeline: add more functions to routing-pipeline

On Thu, Oct 01, 2015 at 12:37:51PM +, Dumitrescu, Cristian wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > > Sent: Thursday, October 1, 2015 12:01 PM > > To: Singh, Jasvinder > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote: > Non-virtualized setups have an iommu available, but they can also use > pci_uio_generic without patching if they like. Not with VFs, they can't. -- MST

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote: > >There were some tentative to get it for other (older) drivers, named > >'bifurcated drivers', but it is stalled. > > IIRC they still exposed the ring to userspace. How much would a ring write syscall cost? 1-2 microseconds, isn't it?

[dpdk-dev] [PATCH] ixgbe: fix 82599 / 82598 register differences

Ixgbe based 82598 and 82599 have different priority recieve link-on register addresses. This is solved in base/ by providing in the PXONRXC and PXONXCNT as seperate macros. This patch ensures the correct address is read, avoiding reading garbage values. Also PXON2OFFCNT doesn't exist in 82598, so

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 01:07 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:38:51PM +0300, Avi Kivity wrote: >> The sad thing is that you can do this since forever on a non-virtualized >> system, or on a virtualized system if you don't need interrupt support. All >> you're doing is blocking i

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:38:51PM +0300, Avi Kivity wrote: > The sad thing is that you can do this since forever on a non-virtualized > system, or on a virtualized system if you don't need interrupt support. All > you're doing is blocking interrupt support on virtualized systems. True, Linux cou

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 02:23:17PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:08:07PM +0100, Bruce Richardson wrote: > > On Thu, Oct 01, 2015 at 01:38:37PM +0300, Michael S. Tsirkin wrote: > > > On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote: > > > > > > > > > > > >

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: >> It's easy to claim that >> a solution is around the corner, only no one was looking for it, but the >> reality is that kernel bypass has been a solution for years for high >> perform

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: > It's easy to claim that > a solution is around the corner, only no one was looking for it, but the > reality is that kernel bypass has been a solution for years for high > performance users, I never said that it's trivial. It's probabl

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:48 PM, Vincent JARDIN wrote: > On 01/10/2015 11:43, Avi Kivity wrote: >> >> That is because the device itself contains an iommu. > > Yes. > > It could be an option: > - we could flag the Linux system unsafe when the device does not > have any IOMMU > - we flag the Linux syst

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:42 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: >> even when they are some users >> prefer to avoid the performance penalty. > I don't think there's a measureable penalty from passing through the > IOMMU, as long as mappings are mostly

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 07:57 AM, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 13:59:02 +0300 > Avi Kivity wrote: > >> On 10/01/2015 01:28 AM, Stephen Hemminger wrote: >>> This is a new UIO device driver to allow supporting MSI-X and MSI devices >>> in userspace. It has been used in environments like VMwa

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:42 PM, Vincent JARDIN wrote: > On 01/10/2015 11:22, Avi Kivity wrote: >>> As far as I could see, without this kind of motivation, people do not >>> even want to try. >> >> You are mistaken. The problem is a lot harder than you think. >> >> People didn't go and write userspace dr

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: > even when they are some users > prefer to avoid the performance penalty. I don't think there's a measureable penalty from passing through the IOMMU, as long as mappings are mostly static (i.e. iommu=pt). I sure never saw any numbers th

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:29 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:15:49PM +0300, Avi Kivity wrote: >> What userspace can't be allowed to do: >> >> access BAR >> write rings >> >> >> >> >> It can access the BAR by mmap()ing the resourceN files under sysf

[dpdk-dev] [PATCH v2] ip_pipeline: add more functions to routing-pipeline

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Thursday, October 1, 2015 12:01 PM > To: Singh, Jasvinder > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ip_pipeline: add more functions to > routing-pipeline > > > > > /* > >

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 12:15:49PM +0300, Avi Kivity wrote: > What userspace can't be allowed to do: > > access BAR > write rings > > > > > It can access the BAR by mmap()ing the resourceN files under sysfs.? You're > not > denying userspace the ability to oops the

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 12:15 PM, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote: >> I still don't understand your objection to the patch: >> >> >> MSI messages are memory writes so any generic device capable >> of MSI is capable of corrupting kernel memory

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 11:44:28AM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote: > > > And for what, to prevent > > > root from touching memory via dma that they can access in a million other > > > ways? > > > > So one can be reasonably sure

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 11:52 AM, Avi Kivity wrote: > > > On 10/01/2015 11:44 AM, Michael S. Tsirkin wrote: >> On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote: And for what, to prevent root from touching memory via dma that they can access in a million other ways? >>> So o

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote: > I still don't understand your objection to the patch: > > > MSI messages are memory writes so any generic device capable > of MSI is capable of corrupting kernel memory. > This means that a bug in userspace will lead to ker

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, Oct 01, 2015 at 01:38:37PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote: > > > > > > On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote: > > >On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote: > > >>It's easy to claim that > > >>a so

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/2015 11:44 AM, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote: >>> And for what, to prevent >>> root from touching memory via dma that they can access in a million other >>> ways? >> So one can be reasonably sure a kernel oops is not a resu

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 01/10/2015 11:43, Avi Kivity wrote: > > That is because the device itself contains an iommu. Yes. It could be an option: - we could flag the Linux system unsafe when the device does not have any IOMMU - we flag the Linux system safe when the device has an IOMMU

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/15 11:44, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote: >>> And for what, to prevent >>> root from touching memory via dma that they can access in a million other >>> ways? >> So one can be reasonably sure a kernel oops is not a result of

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote: > > And for what, to prevent > > root from touching memory via dma that they can access in a million other > > ways? > > So one can be reasonably sure a kernel oops is not a result of a > userspace bug. Actually, I thought about

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 01/10/2015 11:22, Avi Kivity wrote: >> As far as I could see, without this kind of motivation, people do not >> even want to try. > > You are mistaken. The problem is a lot harder than you think. > > People didn't go and write userspace drivers because they were lazy. > They wrote them because

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Wed, Sep 30, 2015 at 03:28:56PM -0700, Stephen Hemminger wrote: > This is a new UIO device driver to allow supporting MSI-X and MSI devices > in userspace. It has been used in environments like VMware and older versions > of QEMU/KVM where no IOMMU support is available. > > Stephen Hemminger (

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

On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > This driver allows using PCI device with Message Signalled Interrupt > from userspace. The API is similar to the igb_uio driver used by the DPDK. > Via ioctl it provides a mechanism to map MSI-X interrupts into event > file descri

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On 10/01/15 00:36, Stephen Hemminger wrote: > On Wed, 30 Sep 2015 23:09:33 +0300 > Vlad Zolotarov wrote: > >> >> On 09/30/15 22:39, Michael S. Tsirkin wrote: >>> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote: >> How would iommu >> virtualization change anything? > Ke

[dpdk-dev] Is there any example application to used DPDK packet distributor library?

Dear Bruce Richardson and DPDK experts. Thank you very much for your the best great efforts and precious answers. I will study and think about it. Thank you very much. Sincerely Yours, Ick-Sung Choi. -Original Message- From: "Bruce Richardson" To: "???"

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

On Thu, 1 Oct 2015 19:31:08 +0300 "Michael S. Tsirkin" wrote: > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote: > > > This driver allows using PCI device with Message Signalled Interrupt > > > from userspac

[dpdk-dev] [PATCH v2] ip_pipeline: add more functions to routing-pipeline

This patch adds following features to the routing-pipeline to enable it for various NFV use-cases; 1.Fast-path ARP table enable/disable 2.Double-tagged VLAN (Q-in-Q) packet enacapsulation for the next-hop 3.MPLS encapsulation for the next-hop 4.Add colour (Traffic-class for QoS) to the MPLS tag 5.

[dpdk-dev] Regarding MMIO

Hi, If we go through the DPDK code it is observed that we are using MMIO for Virt-IO devices. But in the Virt-IO specification, it is written that from Virt-IO 1.0 onwards only they are supporting MMIO, all previous versions uses Port IO for RX/TX notifications. So, If I use VirtIO 0.9, Can I get

[dpdk-dev] Unlinking hugepage backing file after initialiation

On Wed, Sep 30, 2015 at 10:04:36PM +, shesha Sreenivasamurthy (shesha) wrote: > My bad that I said its not working, apologies. > > Isn?t it correct to say that single process application do not benefit from > having backing files ? In that case can make this configurable by passing a > comm

[dpdk-dev] [PATCH v2] ip_pipeline: add more functions to routing-pipeline

> -Original Message- > From: Singh, Jasvinder > Sent: Thursday, October 1, 2015 10:05 AM > To: dev at dpdk.org > Cc: Dumitrescu, Cristian > Subject: [PATCH v2] ip_pipeline: add more functions to routing-pipeline > > *v2 changes: > - fixed bug in print_route > > Signed-off-by: Jasvinder

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Wed, Sep 30, 2015 at 11:36:58PM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 11:00:49PM +0300, Gleb Natapov wrote: > > > You are increasing interrupt latency by a huge factor by channeling > > > interrupts through a scheduler. Let user install an > > > interrupt handler function,

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

On Thu, 1 Oct 2015 14:32:19 +0300 Avi Kivity wrote: > On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote: > > On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: > >> People will just use out of tree drivers (dpdk has several already). It's > >> a > >> pain, but nowhere near what you are

[dpdk-dev] [PATCH v2 04/11] virtio: add xstats() implementation

> From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > +/* [rt]x_qX_ is prepended to the name string here */ static const > > +struct rte_virtio_xstats_name_off rte_virtio_q_stat_strings[] = { > > + {"packets", offsetof(struct virtqueue, packets)}, > > + {"bytes", offsetof(struct

[dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 13:59:02 +0300 Avi Kivity wrote: > On 10/01/2015 01:28 AM, Stephen Hemminger wrote: > > This is a new UIO device driver to allow supporting MSI-X and MSI devices > > in userspace. It has been used in environments like VMware and older > > versions > > of QEMU/KVM where no IOM

  1   2   >