[dpdk-dev] [PATCHv2 4/4] ethdev: fix compiler warning on PMD_DEBUG_TRACE formats

icc 12.1 complains about RTE_LOG() format: "argument is incompatible with corresponding format string conversion" Signed-off-by: Konstantin Ananyev --- lib/librte_ether/rte_ethdev.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/lib/librte_ether/rte_ethdev.c

[dpdk-dev] [PATCHv2 3/4] ethdev: prevent from starting/stopping already started/stopped device

From: Konstantin Ananyev Signed-off-by: Konstantin Ananyev --- lib/librte_ether/rte_ethdev.c | 16 1 file changed, 16 insertions(+) diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index 11e877b..47bcee1 100644 ---

[dpdk-dev] [PATCHv2 2/4] igb/ixgbe: reset queue pointers after releasing

Signed-off-by: Konstantin Ananyev --- lib/librte_pmd_e1000/igb_rxtx.c | 4 +++- lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8 ++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/librte_pmd_e1000/igb_rxtx.c b/lib/librte_pmd_e1000/igb_rxtx.c index e35649f..712086a 100644 ---

[dpdk-dev] [PATCHv2 1/4] e1000: do not release queue on alloc error

If igb_alloc_rx_queue_mbufs() would fail to allocate an mbuf for RX queue, it calls igb_rx_queue_release(rxq). That causes rxq to be silently freed, without updating dev->data->rx_queues[]. So any further reference to it will trigger the SIGSEGV. Same thing in em PMD too. To fix:

[dpdk-dev] [PATCHv2 0/4] fix for 2 consecutive rte_eth_dev_start() can cause a SIGSEGV

Konstantin Ananyev (4): e1000: do not release queue on alloc error igb/ixgbe: reset queue pointers after releasing ethdev: fix compiler warning on PMD_DEBUG_TRACE formats ethdev: prevent from starting/stopping already started/stopped v2 changes: Split one patch into series of 4.

[dpdk-dev] [PATCH v2 0/3] Support setting link up and link down

2014-06-04 15:36, Cao, Waterman: > Tested-by: Waterman Cao > > This patch is used to fix bug, and has been tested by Intel. > We verified API by testpmd, it passed. > Please see test steps as the following: > 1. In the host machine, set the DPDK environment as usual and start testpmd: >

[dpdk-dev] could not l2fwd in DOM0

Jijiang's patch has been applied on master branch: http://dpdk.org/browse/dpdk/commit/?id=6f0ce7b9cd490 2014-05-29 10:12, Liu, Jijiang: > Ok, I will send a patch for fixing this. > > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent:

[dpdk-dev] [PATCH]xen:fix an issue about memory size caculation in Dom0 driver

2014-06-03 21:00, Jijiang Liu: > The unit of allocated_size is MB,so the change below is made. Otherwise, it > will fail to free memory when available memory is not enough. > > Signed-off-by: Jijiang Liu > Acked-by: Huawei Xie > Tested-by: Heng Ding Applied for version 1.7.0. Thanks --

[dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app

Cristian, Please see some comments below. On 06/09/2014 03:25 PM, Dumitrescu, Cristian wrote: > 1. As the name implies, pktmbuf should be used for packets and ctrlmbuf > should be used for control messages . IMHO using pktmbuf to control > messages is a confusing workaround. If ctrlmbuf are

[dpdk-dev] [PATCH] fix for rte_acl: when all rules are wildcards rte_classify() will not work correclty

To reproduce the problem: $ cat rule1 @0.0.0.0/0 0.0.0.0/0 0 : 65535 0 : 65535 0x00/0x00 $ cat trace1 0xc80a0001 0x640a0001 11 1016 $ testacl -n 1 -c 0x1 -- --rulesf=rule1 --tracef=trace1 Note that rte_acl_classify_scalar() still works correctly for that case. The problem is that

[dpdk-dev] [PATCH v2 1/4] Link Bonding Library

On Wed Jun 04 16:18:53 +0100 2014, Declan Doherty wrote: > - Broadcast TX burst broadcast bug fix > - Add/remove slave behavior fix > - Checkpatch fixes Declan, would you consider the following change to rte_bond.c? The two header files from librte_cmdline don't seem to be necessary. Eric

[dpdk-dev] [PATCH] kni: fix compile errors on Oracle Linux6.4 and RHEL6.5

From: HELIN ZHANG The compile errors are as follows. The fixes came from standard Linux drivers of ixgbe-3.21.2 and igb-5.1.2. * Oracle Linux6.4 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h:3111: error: redefinition of 'ether_addr_equal'

[dpdk-dev] kni creation

Hello, the function rte_kni_alloc, which creates a kni interface, requires "const struct rte_kni_conf * conf" as second parameter. This struct contains, among the others, the elements "add" and "id". In the example of kni provided with dpdk, they are set to the pci address and id of a physical

[dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app

Hi Christian, > We need a message type defined for message passing between cores, and > pktmbuf is definitely not the right approach. Could you please explain why a pktmbuf is not the right approach? As proposed in http://dpdk.org/ml/archives/dev/2014-May/002759.html I think the control mbuf

[dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app

Hi Olivier, A few notes on using pktmbuf here: 1. As the name implies, pktmbuf should be used for packets and ctrlmbuf should be used for control messages :). IMHO using pktmbuf to control messages is a confusing workaround. 2. Pktmbuf has a lot of overhead that is not needed in order to send

[dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app

Hi Cristian, On 06/04/2014 08:08 PM, Cristian Dumitrescu wrote: > This Packet Framework sample application illustrates the capabilities of the > Intel DPDK Packet Framework toolbox. > > It creates different functional blocks used by a typical IPv4 framework like: > flow classification,

[dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app

Hi Olivier, We could remove the ctrlmbuf from this app and replace it with something else, but I am afraid we do not have that something else yet defined and agreed. And I would like to avoid doing the same work twice: change this app now to replace the ctrlmbuf with something else, and then

[dpdk-dev] IMPORTANT: feature freeze for version 1.7.0

>---Original Message- >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon >Sent: Friday, May 30, 2014 9:12 PM >To: dev at dpdk.org >Subject: [dpdk-dev] IMPORTANT: feature freeze for version 1.7.0 > >Hello all, > >We have a lot of new features mostly ready for DPDK 1.7.0.