[dpdk-dev] [PATCH] mk: pass CROSS_COMPILE when compiling kernel modules

Hi, 07/02/2014 18:44, Aaro Koskinen : > Pass CROSS_COMPILE to the kernel build system when compiling kernel > modules. Although we export CC etc. the top level kernel Makefile will > override the environment. As a result it will end up using wrong tools > if cross-compilation is desired but CROSS_

[dpdk-dev] l2fwd/l3fwd performance drop of about 25% ?

Hi all, I have a quick question regarding the performance of DPDK l2fwd (Same problem with l3fwd). I am seeing that when we start multiple ports (e.g., 12 ports), for 64 byte packets, the RX rate is only at around 11 Mpps per port, instead of 14.88 Mpps which is the line rate (with preablem+start

[dpdk-dev] Unusable interfaces although apparently attached to IGB_UIO

25/02/2014 14:27, Marc Sune: > 9290 PMD: eth_ixgbe_dev_init(): Hardware Initialization Failure: -30 > > A quick grep over the DPDK code; > > 58:84221:lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h:3189:#define > IXGBE_ERR_SFP_SETUP_NOT_COMPLETE-30 This problem arises when frequency is changing. The

[dpdk-dev] Unusable interfaces although apparently attached to IGB_UIO

Thank you, This is the summary: 9241 PMD: ixgbe_reset_pipeline_82599(): auto negotiation not completed 9242 9243 PMD: ixgbe_setup_sfp_modules_82599(): sfp module setup not complete 9244 9245 PMD: ixgbe_check_mac_link_generic(): ixgbe_check_mac_link_generic 9246 PMD: ixgbe_get_mac_addr_generic():

[dpdk-dev] Unusable interfaces although apparently attached to IGB_UIO

Dear all, We've been experiencing problems with interfaces being recognised by DPDK since some time now, I think since the very begining we started using DPDK (aprox. 1.3). Randomly, even on a fresh reboot (after modprobe->attach->launch dpdk_app), and properly attached to the IGB_UIO kmod [0]

[dpdk-dev] Unusable interfaces although apparently attached to IGB_UIO

Hi, Probably try to rebuild with CONFIG_RTE_LIBRTE_IXGBE_DEBUG_*=y and rerun? Might be it would give you some insight what is going wrong. Konstantin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc Sune Sent: Tuesday, February 25, 2014 12:20 PM To: Subject:

[dpdk-dev] [PATCH] hash: reverse the operand order to crc32 in rte_hash_crc.h

25/02/2014 11:07, H. Peter Anvin: > From: "H. Peter Anvin" > > Checkin > > a132a9cf2bcd440a974b9d3f5c44ba30b2c895a1 hash: use intrinsic > > changed the rte_hash_crc.h from using the crc32 instruction via inline > assembly to using an intrinsic. The intrinsic should allow for better > compiler

[dpdk-dev] DPDK on Xen Server

hi I'm trying running the latest version of INTEL DPDK on my virtualized guest upon a xen server. The guest is gentoo, and kernel version 2.6.39, compiled without xen support, since I don't want to use the virtio function. The host is 2.6.32.43-0.4.1.xs1.6.10.734.170748xen. I'v done

[dpdk-dev] [PATCH] hash: reverse the operand order to crc32 in rte_hash_crc.h

From: "H. Peter Anvin" Checkin a132a9cf2bcd440a974b9d3f5c44ba30b2c895a1 hash: use intrinsic changed the rte_hash_crc.h from using the crc32 instruction via inline assembly to using an intrinsic. The intrinsic should allow for better compiler performance, but the change did not account for the

[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization

Hi, About e1000 - I suppose you refer to the eth_igb_dev_init()->e1000_setup_init_funcs(hw, TRUE)-> e1000_init_nvm_params(hw)? If so, I suppose we can do something like that to overcome it: e1000_setup_init_funcs(hw, FALSE); e1000_reset_swfw_lock(hw); e1000_setup_init_funcs(hw, TRUE); ? First s