[dpdk-dev] [PATCH] vfio: make container open error non-fatal

When setting up an app to run using the uio driver, errors caused by VFIO failures should not abruptly cause the app to fail. Example: on a board with 8 ports bound to igb_uio module, and no VFIO configuration, a testpmd run currently fails with: EAL: cannot open VFIO container! EAL:

[dpdk-dev] [v2 00/23] Packet Framework

2014-06-04 19:08, Cristian Dumitrescu: > > Intel DPDK Packet Framework provides a standard methodology (logically > > similar to OpenFlow) for rapid development of complex packet processing > > pipelines out of ports, tables and actions. > > > > A pipeline is constructed by connecting its input

[dpdk-dev] [PATCH] rte_memory.h: include stdio.h for FILE

Hi Shimamoto: At least rte_tailq.h, rte_mbuf.h should also include stdio.h. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hiroshi Shimamoto Sent: Thursday, June 12, 2014 4:11 PM To: dev at dpdk.org Cc: Hayato Momma Subject: [dpdk-dev] [PATCH] rte_memory.h:

[dpdk-dev] Need help to run l2fwd-ivshmem

Hi, Can anyone give some guide about how to run l2fwd-ivshmem, I run host binary by "host -c 7 -n 3", but got "EAL: No free hugepages reported in hugepages-2048kB", how can I make l2fwd-ivshmem work? Another question, is the guest receive data from host binary? Best Regards John Gong

[dpdk-dev] Need help to run l2fwd-ivshmem

Hugepages issue solved, but I got the this print line "EAL: No IVSHMEM configuration found!", does l2fwd-ivshmem need ovdk to create a ivshmem port? -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of GongJinrong Sent: Tuesday, June 17, 2014 2:50 PM To: dev at dpdk.org

[dpdk-dev] vfio detection

Hi Bruce, > I have a number of NIC ports which were working correctly yesterday and are > bound correctly to the igb_uio driver - and I want to keep using them > through the igb_uio driver for now, not vfio. However, whenever I run a > dpdk application today, I find that the vfio kernel module is

[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers

Hello Konstantin, On 06/16/2014 07:07 PM, Ananyev, Konstantin wrote: > > 1) [PATCH v2 3/7] ethdev: store min rx buffer size > @@ -879,6 +879,8 @@ rte_eth_rx_queue_setup(uint8_t port_id, uint16_t > rx_queue_id, > const struct rte_eth_rxconf *rx_conf, >

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

Hi Bruce, > The below patch is the quickest fix I found to make my applications work > again, but I'm not sure it's the best solution. Can anyone else offer other > suggestions to improve this? Are you running things as root? If not, I suggest to try and use the setup.sh script to correct

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

Hi Bruce, > Hi Bruce, > > > The below patch is the quickest fix I found to make my applications > > work again, but I'm not sure it's the best solution. Can anyone else > > offer other suggestions to improve this? > > Are you running things as root? If not, I suggest to try and use the setup.sh

[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers

Hi David, >> >> 1) [PATCH v2 3/7] ethdev: store min rx buffer size >> @@ -879,6 +879,8 @@ rte_eth_rx_queue_setup(uint8_t port_id, uint16_t >> rx_queue_id, >> const struct rte_eth_rxconf *rx_conf, >> struct rte_mempool *mp) >> { >> ... >> +if (!ret)

[dpdk-dev] [PATCH v2] ethdev: add Rx error counters for missed, badcrc and badlen packets

> > From: Ivan Boule > > > > Split input error stats to have a better understanding of why packets > > have been dropped. > > Keep ierrors field untouched for backward compatibility. > > > > Signed-off-by: Ivan Boule > > Signed-off-by: David Marchand > > Signed-off-by: Thomas Monjalon > >

[dpdk-dev] [PATCH 0/7] Make DPDK tailqs fully local

Found a few races, a v2 will be submitted shortly. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anatoly Burakov > Sent: Friday, June 13, 2014 4:29 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/7] Make DPDK tailqs fully local Best regards,

[dpdk-dev] [PATCH v2] ixgbe: Fix for 82599 Bypass NIC, getting incorrect media type

> Function ixgbe_get_media_type_82599 returns media_type = > ixgbe_media_type_unknown, when using an 82599 Bypass NIC, > so that causes link status interrupt not to work properly. > > change in v2: Fixed compilation error when RTE_NIC_BYPASS=n > > Signed-off-by: Pablo de Lara > --- >

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

On Mon, Jun 16, 2014 at 10:30:54PM +, Richardson, Bruce wrote: > The below patch is the quickest fix I found to make my applications work > again, but I'm not sure it's the best solution. Can anyone else offer other > suggestions to improve this? > > > -Original Message- > > From:

[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers

>As you konw, rte_ether.h is for ethernet definition >(and should be located in librte_net). >For RTE_IPV4_MIN_MTU, I think librte_net/rte_ip.h is more appropriate. Yes, it is. Konstantin

[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers

On 06/17/2014 10:57 AM, Ananyev, Konstantin wrote: > Yes, I understand that it will be initialised to 0 together with whole > dev->data. > But then, the condition: > if (dev->data->min_rx_buf_size > mbp_buf_size) > would never be true, and min_rx_buf_size would always remain 0? > I thought you

[dpdk-dev] Unable to send Response packets to the same port

Update: I forgot to mention that in our case, due to some our internal constrains code always allocates new m_buf for received packet and adds additional overhead PDU to it (both ways) It seems that problem lies with the same mempool being used. We've tried to create another mempool for packet

[dpdk-dev] [PATCH 1/2] kni: fix build with kernel 3.16

SET_ETHTOOL_OPS is gone in 3.16, so modify drivers accordingly. Signed-off-by: Aaro Koskinen --- lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 4 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h | 5 + lib/librte_eal/linuxapp/kni/kni_ethtool.c | 2 +- 3 files

[dpdk-dev] [PATCH 2/2] kni: igb: modify rate configation to support min/max rate fields

This follows the mainline Linux kernel commit ed616689a3d95eb6c9bdbb1ef74b0f50cbdf276a (Add support to configure SR-IOV VF minimum and maximum Tx rate) by Sucheta Chakraborty, and enables to build the driver against 3.16. Signed-off-by: Aaro Koskinen ---

[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers

>- Actually, looking at dev->data structure, there is something >suspicious to me. >From what I understood, secondary processes are not supposed to touch >dev->data, at it is shared between processes. >So I don't understand why rte_eth_dev_allocate() writes >dev->data->port_id, without looking

[dpdk-dev] [PATCH 9/9] rte_acl: make acl tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_acl/acl.h | 1 - lib/librte_acl/rte_acl.c | 74 +++- 2 files changed, 60 insertions(+), 15 deletions(-) diff --git a/lib/librte_acl/acl.h b/lib/librte_acl/acl.h index e6d7985..b9d63fd 100644 ---

[dpdk-dev] [PATCH 4/9] rte_hash: make rte_hash tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_hash/rte_hash.c | 61 +++--- lib/librte_hash/rte_hash.h | 2 -- 2 files changed, 52 insertions(+), 11 deletions(-) diff --git a/lib/librte_hash/rte_hash.c b/lib/librte_hash/rte_hash.c index d4221a8..eea5c01

[dpdk-dev] [PATCH 0/9] Make DPDK tailqs fully local

This issue was reported by OVS-DPDK project, and the fix should go to upstream DPDK. This is not memnic-related - this is to do with DPDK's rte_ivshmem library. Every DPDK data structure has a corresponding TAILQ reserved for it in the runtime config file. Those TAILQs are fully local to the

[dpdk-dev] [PATCH 8/9] rte_lpm6: make lpm6 tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_lpm/rte_lpm6.c | 62 ++- 1 file changed, 51 insertions(+), 11 deletions(-) diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c index 56c74a1..73b48d0 100644 --- a/lib/librte_lpm/rte_lpm6.c

[dpdk-dev] [PATCH 5/9] rte_fbk_hash: make rte_fbk_hash tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_hash/rte_fbk_hash.c | 73 ++ lib/librte_hash/rte_fbk_hash.h | 3 -- 2 files changed, 59 insertions(+), 17 deletions(-) diff --git a/lib/librte_hash/rte_fbk_hash.c b/lib/librte_hash/rte_fbk_hash.c index

[dpdk-dev] [PATCH 3/9] rte_ring: make ring tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 17 ++-- lib/librte_ring/Makefile | 4 ++-- lib/librte_ring/rte_ring.c| 33 +++ lib/librte_ring/rte_ring.h| 2 -- 4 files

[dpdk-dev] [PATCH 6/9] rte_mempool: make mempool tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_mempool/Makefile | 3 ++- lib/librte_mempool/rte_mempool.c | 37 - lib/librte_mempool/rte_mempool.h | 2 -- 3 files changed, 30 insertions(+), 12 deletions(-) diff --git a/lib/librte_mempool/Makefile

[dpdk-dev] [PATCH 1/9] eal: map shared config into exact same address as primary process

Shared config is shared across primary and secondary processes. However,when using rte_malloc, the malloc elements keep references to the heap inside themselves. This heap reference might not be referencing a local heap because the heap reference points to the heap of whatever process has

[dpdk-dev] [PATCH 2/9] rte_tailq: change rte_dummy to rte_tailq_entry, add data pointer

Signed-off-by: Anatoly Burakov --- app/test/test_tailq.c | 33 --- lib/librte_eal/common/eal_common_tailqs.c | 2 +- lib/librte_eal/common/include/rte_tailq.h | 9 + 3 files changed, 23 insertions(+), 21 deletions(-) diff --git

[dpdk-dev] [PATCH 7/9] rte_lpm: make lpm tailq fully local

Signed-off-by: Anatoly Burakov --- lib/librte_lpm/rte_lpm.c | 65 lib/librte_lpm/rte_lpm.h | 2 -- 2 files changed, 54 insertions(+), 13 deletions(-) diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c index 592750e..6a49d43 100644

[dpdk-dev] [PATCH v2] malloc: fix malloc and free linear complexity

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of > rsanford2 at gmail.com > Sent: Friday, May 16, 2014 1:59 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] malloc: fix malloc and free linear complexity > > Problems with lib rte_malloc: > 1.

[dpdk-dev] [PATCH v2 00/27] Add i40e PMD support

> The 2nd version of series of patches are to add i40e PMD support. > It contains the updated basic shared code, and some other enhancements. > It adds the support of the latest version of firmware. > * Add new PMD driver of i40e in the folder of librte_pmd_i40e > * Add some neccessary

[dpdk-dev] [PATCH v2] malloc: fix malloc and free linear complexity

Hi Pablo, > Overall patch looks OK, but malloc unit tests fail on the last test (test_multi_alloc_statistics). > Apparently, the biggest free chunk size changes as it allocates some memory, whereas in > the previous implementation, this size did not change. I wonder if unit test is wrong or if

[dpdk-dev] vfio detection

> -Original Message- > From: Burakov, Anatoly > Sent: Tuesday, June 17, 2014 1:40 AM > To: Richardson, Bruce; dev at dpdk.org > Subject: RE: vfio detection > > Hi Bruce, > > > I have a number of NIC ports which were working correctly yesterday and are > > bound correctly to the igb_uio

[dpdk-dev] [PATCH 1/9] eal: map shared config into exact same address as primary process

Hi Anatoly > > Shared config is shared across primary and secondary processes. > However,when using rte_malloc, the malloc elements keep references to > the heap inside themselves. This heap reference might not be referencing > a local heap because the heap reference points to the heap of

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

> -Original Message- > From: Burakov, Anatoly > Sent: Tuesday, June 17, 2014 1:52 AM > To: Richardson, Bruce; dev at dpdk.org > Subject: RE: [PATCH] vfio: make container open error non-fatal > > Hi Bruce, > > > The below patch is the quickest fix I found to make my applications work >

[dpdk-dev] vfio detection

Bruce, your log files have been automatically removed on the mailing list. It's simpler to put logs in the email body. -- Thomas

[dpdk-dev] vfio detection

Yes, so I see. Resending with log in body. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, June 17, 2014 9:36 AM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] vfio detection > > Bruce, your log files have been

[dpdk-dev] vfio detection

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Richardson, Bruce > Sent: Tuesday, June 17, 2014 9:29 AM > To: Burakov, Anatoly; dev at dpdk.org > Subject: Re: [dpdk-dev] vfio detection > > > -Original Message- > > From: Burakov, Anatoly > > Sent:

[dpdk-dev] [PATCH] vfio: open VFIO container at startup rather than during init

> -Original Message- > From: Burakov, Anatoly > Sent: Tuesday, June 17, 2014 2:12 AM > To: dev at dpdk.org > Cc: Richardson, Bruce > Subject: [PATCH] vfio: open VFIO container at startup rather than during init > > > Signed-off-by: Anatoly Burakov > --- This seems to fix the issue I

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

> -Original Message- > From: Richardson, Bruce > Sent: Monday, June 16, 2014 3:29 PM > To: dev at dpdk.org > Cc: Richardson, Bruce > Subject: [PATCH] vfio: make container open error non-fatal > > When setting up an app to run using the uio driver, errors caused by > VFIO failures should

[dpdk-dev] [PATCH] vfio: open VFIO container at startup rather than during init

> Signed-off-by: Anatoly Burakov Please Anatoly, could you provide a text explaining what was broken and why you fixed it this way? Thanks -- Thomas

[dpdk-dev] [dpdk-stv] [PATCH 1/1] Fix the pointer 'ctx1' uninitialized error with gcc 4.5.1

2014-06-16 11:22, Min Cao: > Discription: This patch is aimed to fix the the pointer 'ctx1' uninitialized > error with gcc4.5.1 as described below: > "dpdk/lib/librte_kvargs/rte_kvargs.c:51:14: error: 'ctx1' may be used > uninitialized in this function" > > Signed-off-by: Cao Min > Acked-by:

[dpdk-dev] vfio detection

On Tue, Jun 17, 2014 at 04:38:38PM +, Richardson, Bruce wrote: > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Richardson, Bruce > > Sent: Tuesday, June 17, 2014 9:29 AM > > To: Burakov, Anatoly; dev at dpdk.org > > Subject: Re: [dpdk-dev] vfio

[dpdk-dev] vfio detection

> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Tuesday, June 17, 2014 10:42 AM > To: Richardson, Bruce > Cc: Burakov, Anatoly; dev at dpdk.org > Subject: Re: [dpdk-dev] vfio detection > > On Tue, Jun 17, 2014 at 04:38:38PM +, Richardson, Bruce

[dpdk-dev] [PATCH v3 0/7] add mtu and flow control handlers

This patchset introduces 3 new ethdev operations: flow control parameters retrieval and mtu get/set operations. Changes since v1: - compute min rx buffer size at ethdev level (to simplify pmd mtu checks) - introduce enable_scatter rx mode so that we can advise pmd to configure scatter mode -

[dpdk-dev] [PATCH v3 1/7] ethdev: retrieve flow control configuration

From: Zijie Pan This patch adds a new function in ethdev api to retrieve current flow control configuration. This operation has been implemented for rte_em_pmd, rte_igb_pmd and rte_ixgbe_pmd. Signed-off-by: Zijie Pan Signed-off-by: David Marchand ---

[dpdk-dev] [PATCH v3 2/7] ethdev: add autoneg parameter in flow ctrl accessors

Add autoneg field in flow control parameters. This makes it easier to understand why changing some parameters does not always have the expected result. Changing autoneg is not supported at the moment. Signed-off-by: David Marchand --- lib/librte_ether/rte_ethdev.h |1 +

[dpdk-dev] [PATCH v3 3/7] ethdev: store min rx buffer size

This avoids code duplication in PMD when dealing with mtu changes. Signed-off-by: David Marchand --- lib/librte_ether/rte_ethdev.c | 20 +++- lib/librte_ether/rte_ethdev.h |3 +++ 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/lib/librte_ether/rte_ethdev.c

[dpdk-dev] [PATCH v3 4/7] ethdev: introduce enable_scatter rx mode

We might want to be sure the scatter packets reception handler is selected in a pmd. This makes it possible to then change mtu later, without the need of restarting a port. It is then the pmd duty to tell it enabled the scatter reception handler by setting dev->data->scattered_rx to 1.

[dpdk-dev] [PATCH v3 5/7] ethdev: add mtu accessors

From: Samuel Gauthier This patch adds two new functions in ethdev api to retrieve current MTU and change MTU of a port. Only .mtu_set function is pmd specific. pmd should update its max_rx_pkt_len if needed. This operation has been implemented for rte_em_pmd,

[dpdk-dev] [PATCH v3 6/7] ixgbe: add set_mtu to ixgbevf

From: Ivan Boule The support of jumbo frames in the ixgbevf Poll Mode Driver of 10GbE 82599 VF functions consists in the following enhancements: - Implement the mtu_set function in the ixgbevf PMD, using the IXGBE_VF_SET_LPE request of the version 1.0 of the VF/PF

[dpdk-dev] [PATCH v3 7/7] app/testpmd: allow to configure mtu

From: Ivan Boule Take avantage of the .set_mtu ethdev function and make it possible to configure MTU on devices using testpmd. Signed-off-by: Ivan Boule Signed-off-by: David Marchand --- app/test-pmd/cmdline.c | 54

[dpdk-dev] [PATCH] testpmd: Simplify logic in error branch

Simplifiy the logic in the error checking branch. Rather than having a single error branch which checked both RX and TX conditions and made extensive use of the ? operator, move the error checking explicitly into the RX and TX individual branches. The original code caused compilation issues when

[dpdk-dev] [PATCH] EAL: add format(printf) attrib. to appropriate fns

Mark the rte_log, cmdline_printf and rte_snprintf functions as being printf-style functions. This causes compilation errors due to mis-matched parameter types, so the parameter types are fixed where appropriate. Signed-off-by: Bruce Richardson --- app/cmdline_test/commands.c

[dpdk-dev] vfio detection

On Tue, Jun 17, 2014 at 05:45:55PM +, Richardson, Bruce wrote: > > > > -Original Message- > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Tuesday, June 17, 2014 10:42 AM > > To: Richardson, Bruce > > Cc: Burakov, Anatoly; dev at dpdk.org > > Subject: Re: [dpdk-dev]

[dpdk-dev] [PATCH] vfio: correct system call error checking

Noticed today that ioctl error code return checking was incorrect in some of the vfio code. ioctl can return a negative value if the system detects an error before the target device/driver can produce a return code. The dpdk vfio code only checks specfically for the values that it expects, which

[dpdk-dev] DPDK Support for the i217 ?

Hi all, Just checking once more on a question I have asked back in January: We would like to know if DPDK support for the i217 will be provided anytime soon. The Supported NICs list doesn't show the i217. Intel DPDK Release Notes don't mention the i217 either. The answer I received

[dpdk-dev] [PATCH] vfio: correct system call error checking

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Tuesday, June 17, 2014 12:04 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] vfio: correct system call error checking > > Noticed today that ioctl error code return checking was

[dpdk-dev] [PATCH] vfio: correct system call error checking

On Tue, Jun 17, 2014 at 08:21:29PM +, Richardson, Bruce wrote: > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > > Sent: Tuesday, June 17, 2014 12:04 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH] vfio: correct system call

[dpdk-dev] [PATCH] vfio: correct system call error checking

> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Tuesday, June 17, 2014 1:40 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] vfio: correct system call error checking > > On Tue, Jun 17, 2014 at 08:21:29PM +,

[dpdk-dev] [PATCH v3 0/7] add mtu and flow control handlers

> This patchset introduces 3 new ethdev operations: flow control parameters > retrieval and mtu get/set operations. > > Changes since v1: > - compute min rx buffer size at ethdev level (to simplify pmd mtu checks) > - introduce enable_scatter rx mode so that we can advise pmd to configure >

[dpdk-dev] [PATCH 0/8] virtio driver phase 2

On Fri, 13 Jun 2014 18:06:17 -0700 Stephen Hemminger wrote: > This is second group of patches for cleaning up virtio driver > prior to the functionality changes in next phase. > > Ping.. no comments I have a lot of patches stacked and ready or in testing. And am trying to pace them out a