[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure

On 07/28/2016 02:38 PM, Jerin Jacob wrote: > On Thu, Jul 28, 2016 at 10:36:07AM +, Ananyev, Konstantin wrote: >>> If it does not cope up then it can skip tx'ing in the actual tx burst >>> itself and move the "skipped" tx packets to end of the list in the tx >>> burst so that application can

[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure

On 07/21/2016 06:24 PM, Tomasz Kulasek wrote: > This is an ABI deprecation notice for DPDK 16.11 in librte_ether about > changes in rte_eth_dev and rte_eth_desc_lim structures. > > As discussed in that thread: > > http://dpdk.org/ml/archives/dev/2015-September/023603.html > > Different NIC models

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

On 02/29/2016 01:27 PM, Ferruh Yigit wrote: > On 2/29/2016 10:58 AM, Avi Kivity wrote: >> >> On 02/29/2016 12:43 PM, Ferruh Yigit wrote: >>> On 2/29/2016 9:43 AM, Avi Kivity wrote: >>>> On 02/28/2016 10:16 PM, Ferruh Yigit wrote: >>>>> On 2/28/2

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

On 02/29/2016 12:43 PM, Ferruh Yigit wrote: > On 2/29/2016 9:43 AM, Avi Kivity wrote: >> On 02/28/2016 10:16 PM, Ferruh Yigit wrote: >>> On 2/28/2016 3:34 PM, Avi Kivity wrote: >>>> On 01/27/2016 06:24 PM, Ferruh Yigit wrote: >>>>> This kerne

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

On 02/28/2016 10:16 PM, Ferruh Yigit wrote: > On 2/28/2016 3:34 PM, Avi Kivity wrote: >> On 01/27/2016 06:24 PM, Ferruh Yigit wrote: >>> This kernel module is based on KNI module, but this one is stripped >>> version of it and only for control messages, no data transfer

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

On 01/27/2016 06:24 PM, Ferruh Yigit wrote: > This kernel module is based on KNI module, but this one is stripped > version of it and only for control messages, no data transfer > functionality provided. > > This Linux kernel module helps userspace application create virtual > interfaces and when

[dpdk-dev] [PATCH] vfio: Include No-IOMMU mode

On 11/16/2015 07:06 PM, Alex Williamson wrote: > On Wed, 2015-10-28 at 15:21 -0600, Alex Williamson wrote: >> There is really no way to safely give a user full access to a DMA >> capable device without an IOMMU to protect the host system. There is >> also no way to provide DMA translation, for

[dpdk-dev] Network Stack discussion notes from 2015 DPDK Userspace

On 10/10/2015 02:19 AM, Wiles, Keith wrote: > Here are some notes from the DPDK Network Stack discussion, I can remember > please help me fill in anything I missed. > > Items I remember we talked about: > >* The only reason for a DPDK TCP/IP stack is for performance and > possibly lower

[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 >>

[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] 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

[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 tr

[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 no

[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

[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 o

[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

[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 >

[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

[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 wi

[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 c

[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

[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

[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 soluti

[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

[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

[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. >>

[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 MS

[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 acce

[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

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

On 09/30/2015 11:40 PM, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 06:36:17PM +0300, Avi Kivity wrote: >> As it happens, you're removing the functionality from the users who have no >> other option. They can't use vfio because it doesn't work on virtualized >> setups

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

On 09/30/2015 06:21 PM, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 05:53:54PM +0300, Avi Kivity wrote: >> On 09/30/2015 05:39 PM, Michael S. Tsirkin wrote: >>> On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote: >>>> On 09/30/2015 03:27 PM, Michael

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

On 09/30/2015 05:39 PM, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote: >> >> On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote: >>> On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote: >>>> On 09/30/15 15:03, Mi

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

On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote: >> >> On 09/30/15 15:03, Michael S. Tsirkin wrote: >>> On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote: On 09/30/15 14:41, Michael S. Tsirkin wrote: > On

[dpdk-dev] [ANNOUNCE] ScyllaDB: new NoSQL database powered by DPDK

Hello dpdk-ers, We are pleased to announce Scylla, a new open-source NoSQL database powered by DPDK. Scylla's performance (one million transactions per second per node) derives in part from a user-space TCP/IP stack, using DPDK to drive the network cards. Scylla is open source and can be

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On Sep 13, 2015 6:54 PM, "Ananyev, Konstantin" wrote: > > > > > -Original Message- > > From: Avi Kivity [mailto:avi at cloudius-systems.com] > > Sent: Sunday, September 13, 2015 1:33 PM > > To: Ananyev, Konstantin; Thomas Monjalon; Vlad

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 09/13/2015 02:47 PM, Ananyev, Konstantin wrote: > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Avi Kivity >> Sent: Friday, September 11, 2015 6:48 PM >> To: Thomas Monjalon; Vladislav Zolotarov; didier.pallard >> C

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 09/11/2015 07:08 PM, Thomas Monjalon wrote: > 2015-09-11 18:43, Avi Kivity: >> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote: >>> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" >> <mailto:thomas.monjalon at 6wind.com>> wrote: >>>> 201

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 09/11/2015 07:07 PM, Richardson, Bruce wrote: > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov >> Sent: Friday, September 11, 2015 5:04 PM >> To: Avi Kivity >> Cc: dev at dpdk.org >> Subje

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote: > > > On Sep 11, 2015 5:55 PM, "Thomas Monjalon" <mailto:thomas.monjalon at 6wind.com>> wrote: > > > > 2015-09-11 17:47, Avi Kivity: > > > On 09/11/2015 05:25 PM, didier.pallard wrote: >

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 09/11/2015 05:25 PM, didier.pallard wrote: > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote: >> >> Helin, the issue has been seen on x540 devices. Pls., see a chapter >> 7.2.1.1 of x540 devices spec: >> >> A packet (or multiple packets in transmit segmentation) can span any >> number of >>

[dpdk-dev] Broken RSS hash computation on Intel 82574L

On 09/01/2015 05:47 PM, Matthew Hall wrote: > On Tue, Sep 01, 2015 at 04:37:18PM +0200, Martin Dra?ar wrote: >> Dne 1.9.2015 v 15:45 De Lara Guarch, Pablo napsal(a): >>> 82574L NIC uses em PMD, which does not support more than 1 queue. >>> Therefore RSS is disabled in the NIC and then you cannot

[dpdk-dev] [PATCH] mempool: fix incompatibility with C++ in header file

(adding list+Thomas back to cc) On 08/17/2015 11:33 AM, Olivier MATZ wrote: > Hi, > > On 08/14/2015 10:33 AM, Avi Kivity wrote: >> C++ doesn't allow implied casting from void * to another pointer, so >> supply an explicit cast. >> >> Signed-off-by: Avi Kivity &g

[dpdk-dev] [PATCH] mempool: fix incompatibility with C++ in header file

C++ doesn't allow implied casting from void * to another pointer, so supply an explicit cast. Signed-off-by: Avi Kivity --- lib/librte_mempool/rte_mempool.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool

[dpdk-dev] [PATCH] mbuf: fix incompatibility with C++ in header file

C++ doesn't allow implied casting from void * to another pointer, so supply an explicit cast. Signed-off-by: Avi Kivity --- lib/librte_mbuf/rte_mbuf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h index c3b8c98

[dpdk-dev] RFC: i40e xmit path HW limitation

On 07/30/2015 08:01 PM, Stephen Hemminger wrote: > On Thu, 30 Jul 2015 19:50:27 +0300 > Vlad Zolotarov wrote: > >> >> On 07/30/15 19:20, Avi Kivity wrote: >>> >>> On 07/30/2015 07:17 PM, Stephen Hemminger wrote: >>>> On Thu, 30 Jul 2015 17:57

[dpdk-dev] RFC: i40e xmit path HW limitation

On 07/30/2015 07:17 PM, Stephen Hemminger wrote: > On Thu, 30 Jul 2015 17:57:33 +0300 > Vlad Zolotarov wrote: > >> Hi, Konstantin, Helin, >> there is a documented limitation of xl710 controllers (i40e driver) >> which is not handled in any way by a DPDK driver. >> From the datasheet chapter

[dpdk-dev] [PATCH 1/2] eal/persistent: new library to hold memory region after program exit

On 07/06/2015 04:28 PM, leeopop wrote: > Some NICs use host memory region as their scratch area. > When DPDK user applications terminate, all the memory regions are lost, > re-initialized (memzone), which causes HW faults. > This libraray maintains shared memory regions that is persistent across >

[dpdk-dev] VMXNET3 on vmware, ping delay

On 06/25/2015 09:44 PM, Thomas Monjalon wrote: > 2015-06-25 18:46, Avi Kivity: >> On 06/25/2015 06:18 PM, Matthew Hall wrote: >>> On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia - >>> HU/Budapest) wrote: >>>> According to my understandin

[dpdk-dev] VMXNET3 on vmware, ping delay

On 06/25/2015 06:18 PM, Matthew Hall wrote: > On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia - HU/Budapest) > wrote: >> According to my understanding each packet should go >> through BR as fast as possible, but it seems that the rte_eth_rx_burst >> retrieves packets only when

[dpdk-dev] Beyond DPDK 2.0

On 05/07/2015 06:49 PM, Wiles, Keith wrote: > > On 5/7/15, 8:33 AM, "Avi Kivity" wrote: > >> On 05/07/2015 06:27 PM, Wiles, Keith wrote: >>> On 5/7/15, 7:02 AM, "Avi Kivity" wrote: >>> >>>> On Wed, Apr 22, 2015 at 6:11

[dpdk-dev] Beyond DPDK 2.0

On 05/07/2015 06:27 PM, Wiles, Keith wrote: > > On 5/7/15, 7:02 AM, "Avi Kivity" wrote: > >> On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim >> <tim.o'driscoll at intel.com> >> wrote: >> >>> Does anybody have any input or comments

[dpdk-dev] Beyond DPDK 2.0

On 05/07/2015 06:27 PM, Wiles, Keith wrote: > > On 5/7/15, 7:02 AM, "Avi Kivity" wrote: > >> On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim >> <tim.o'driscoll at intel.com> >> wrote: >> >>> Does anybody have any input or comments

[dpdk-dev] Beyond DPDK 2.0

On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim wrote: > Does anybody have any input or comments on this? > > > > -Original Message- > > From: O'Driscoll, Tim > > Sent: Thursday, April 16, 2015 11:39 AM > > To: dev at dpdk.org > > Subject: Beyond DPDK 2.0 >

[dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options

On 04/09/2015 02:19 PM, Neil Horman wrote: > On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote: >> >> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote: >>> On 08/04/2015 19:26, Stephen Hemminger wrote: >>>> On Wed, 8 Apr 2015 16:07:21 +010

[dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options

On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote: > On 08/04/2015 19:26, Stephen Hemminger wrote: >> On Wed, 8 Apr 2015 16:07:21 +0100 >> Sergio Gonzalez Monroy wrote: >> >>> Currently, the target/rules to build combined libraries is different >>> than the one to build individual

[dpdk-dev] [PATCH v1 5/5] ixgbe: Add LRO support

On 03/04/2015 02:33 AM, Stephen Hemminger wrote: > On Tue, 3 Mar 2015 21:48:43 +0200 > Vlad Zolotarov wrote: > >> + * TODO: >> + *- Get rid of "volatile" crap and let the compiler do its >> + * job. >> + *- Use the proper memory

[dpdk-dev] Appropriate DPDK data structures for TCP sockets

On 02/23/2015 11:16 PM, Matthew Hall wrote: > On Mon, Feb 23, 2015 at 08:48:57AM -0600, Matt Laswell wrote: >> Apologies in advance for likely being a bit long-winded. > Long winded is great, helps me get context. > >> First, you really need to take cache performance into account when you're >>