[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 setup_init_funcs() would just setup hw func pointers and wouldn't call
e1000_init_nvm_params/ e1000_init_phy_params.
Then we reset the lock, then call setup_funcs once again - that time it would
read/write HW regs.
Konstantin
-Original Message-
From: didier.pallard [mailto:didier.pall...@6wind.com]
Sent: Monday, February 24, 2014 2:19 PM
To: Ananyev, Konstantin
Cc: Thomas Monjalon; dev at dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked
semaphores on initialization
Hi,
The patch (or some derivative that do the same result) should probably rather
be integrated in base driver.
For IGB implementation, it is not possible to extract patch from base driver,
since lock release should be done before calls to e1000_init_nvm_params or
e1000_init_phy_params that use the potentially stuck locks and after enough
function pointers fields are filled by e1000_setup_init_funcs to have functions
to access the hardware.
For ixgbe, it may be possible on 82598/82599 using ixgbe_xxx_swfw_semaphore to
do the job from outside the base driver, assuming that no lock will never be
taken by the base driver before the return of ixgbe_init_shared_code function.
But it is not be possible on X540, since this implementation does not use the
ixgbe_get_eeprom_semaphore generic function that automatically release the SMBI
lock on timeout; So the release of this lock should be done using
ixgbe_release_swfw_sync_semaphore that is not accessible through the API.
didier
On 02/21/2014 05:30 PM, Ananyev, Konstantin wrote:
> To be more specific, I am talking about something like the patch below.
> It is just a copy-paste of your fix, but implemented and called from
> ixgbe_ethdev.c Konstantin
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> b/lib/librte_pmd_ixgbe/ixgbe_et hdev.c index 7e068c2..5d8744a 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> @@ -561,6 +561,42 @@ ixgbe_dcb_init(struct ixgbe_hw *hw,struct
> ixgbe_dcb_config
> *dcb_config)
> }
> }
>
> +static void
> +ixgbe_swfw_lock_reset(struct ixgbe_hw *hw) {
> + uint16_t mask;
> +
> + /* Get bus info */
> + hw->mac.ops.get_bus_info(hw);
> +
> + /* Ensure that all locks are released before first NVM or PHY
> + access */
> +
> + /*
> +* Phy lock should not fail in this early stage. If this is the case,
> +* it is due to an improper exit of the application.
> +* So force the release of the faulty lock. Release of common lock
> +* is done automatically by swfw_sync function.
> +*/
> + mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
> + if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
> + DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
> + }
> + hw->mac.ops.release_swfw_sync(hw, mask);
> +
> + /*
> +* Those one are more tricky since they are common to all ports; but
> +* swfw_sync retries last long enough (1s) to be almost sure that if
> +* lock can not be taken it is due to an improper lock of the
> +* semaphore.
> +*/
> + mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM |
> IXGBE_GSSR_SW_MNG_SM;
> + if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
> + DEBUGOUT("SWFW common locks released");
> + }
> + hw->mac.ops.release_swfw_sync(hw, mask); }
> +
> +
> /*
>* This function is based on code in ixgbe_attach() in ixgbe/ixgbe.c.
>* It returns 0 on success.
> @@ -618,6 +654,11 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct
> eth_driver *eth_drv,
> return -EIO;
> }
>
> + if (hw->mac.type == ixgbe_mac_82598EB ||
> + hw->mac.type == ixgbe_mac_82599EB ||
> + hw->mac.type == ixgbe_mac_X540)
> + ixgbe_swfw_lock_reset(hw);
> +
> /* Initialize DCB configuration*/
> memset(dcb_config, 0, sizeof(struct ixgbe_dcb_config));
> ixgbe_dcb_init(hw,dcb_config);
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Wednesday, February 19, 2014 5:52 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked
> semaphores on initialization
>
> Hi Thomas,
> I am afraid I couldn't send you an url we are using.
> We take it from internal Intel ND repository.
> Though I think, that latest available to download from Intel ixgbe driver for
> FreeBSD should have pretty close codebase.
> As a rule of thumb in our internal policy: we take shared code from
[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 the following steps: 1. Compile the DPDK for the gentoo kernel 2. insmod uio.ko and igb_uio.ko 3. unbind the NIC from the original NIC driver, and HERE THE TROUBLES COME... Here is the lspci result on my gentoo: #lspci | grep Ethernet 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:06.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) But when I unbind the pci device :00:05.0 using the following command: echo :00:05.0 > /sys/bus/pci/drivers/e1000/unbind it just hanged, with a process state D+. What's this problem? How could I solve it? Best Regards! machi1271
[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 fact that
the inline assembly being in AT&T syntax used the opposite operand
order of the intrinsic.
This turns out to not matter for correctness, because the CRC32
operation is commutative. However, it could potentially matter for
performance, because the loop is more efficient with the moving
pointer in the source operand and the accumulation in the destination
operand.
This was discovered by Jan Beulich when looking at the equivalent code
in the Linux kernel.
Signed-off-by: H. Peter Anvin
---
lib/librte_hash/rte_hash_crc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index f10f139..1b9481e 100644
--- a/lib/librte_hash/rte_hash_crc.h
+++ b/lib/librte_hash/rte_hash_crc.h
@@ -60,7 +60,7 @@ extern "C" {
static inline uint32_t
rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
{
- return _mm_crc32_u32(data, init_val);
+ return _mm_crc32_u32(init_val, data);
}
/**
--
1.8.5.3
[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 performance, but the change did not account for the fact that > the inline assembly being in AT&T syntax used the opposite operand > order of the intrinsic. > > This turns out to not matter for correctness, because the CRC32 > operation is commutative. However, it could potentially matter for > performance, because the loop is more efficient with the moving > pointer in the source operand and the accumulation in the destination > operand. > > This was discovered by Jan Beulich when looking at the equivalent code > in the Linux kernel. > > Signed-off-by: H. Peter Anvin It was also reported by Pashupati Kumar . Acked and applied. Thanks -- Thomas
[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], interfaces do appear in the "probe stage" of the respective driver during RTE* initialization, but DPDK complains there are no DPDK-enabled interfaces [1]. It even happens with the examples provided [1]. Once they enter in this "zombie state", there is no way to recover them unless a reboot is performed. Attaching igb_uio -> igb -> gb_uio does not solve it either. This happens also with 1G copper ports. Any ideas? Thanks and regards marc p.s. Using 1.5.2 branch right now - [0] setup.sh Option: 10 Network devices using IGB_UIO driver :06:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused= :06:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused= Network devices using kernel driver === :08:00.1 'DH8900CC Series Gigabit Network Connection' if=eth3 drv=igb unused=igb_uio :08:00.2 'DH8900CC Series Gigabit Network Connection' if=eth5 drv=igb unused=igb_uio :08:00.3 'DH8900CC Series Gigabit Network Connection' if=eth6 drv=igb unused=igb_uio :08:00.4 'DH8900CC Series Gigabit Network Connection' if=eth7 drv=igb unused=igb_uio :09:00.0 'I350 Gigabit Network Connection' if=eth8 drv=igb unused=igb_uio *Active* :09:00.1 'I350 Gigabit Network Connection' if=eth9 drv=igb unused=igb_uio *Active* :09:00.2 'I350 Gigabit Network Connection' if=eth10 drv=igb unused=igb_uio :09:00.3 'I350 Gigabit Network Connection' if=eth11 drv=igb unused=igb_uio :85:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth2 drv=ixgbe unused=igb_uio :85:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth4 drv=ixgbe unused=igb_uio Other network devices = Enter PCI address of device to bind to IGB UIO driver: [1] l2fwd marc at bertha-dpdk:~/dpdk/examples/l2fwd/build$ sudo ./l2fwd -c 0xFF -n 2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Detected lcore 8 as core 0 on socket 1 EAL: Detected lcore 9 as core 1 on socket 1 EAL: Detected lcore 10 as core 2 on socket 1 EAL: Detected lcore 11 as core 3 on socket 1 EAL: Detected lcore 12 as core 4 on socket 1 EAL: Detected lcore 13 as core 5 on socket 1 EAL: Detected lcore 14 as core 6 on socket 1 EAL: Detected lcore 15 as core 7 on socket 1 EAL: Skip lcore 16 (not detected) EAL: Skip lcore 17 (not detected) EAL: Skip lcore 18 (not detected) EAL: Skip lcore 19 (not detected) EAL: Skip lcore 20 (not detected) EAL: Skip lcore 21 (not detected) EAL: Skip lcore 22 (not detected) EAL: Skip lcore 23 (not detected) EAL: Skip lcore 24 (not detected) EAL: Skip lcore 25 (not detected) EAL: Skip lcore 26 (not detected) EAL: Skip lcore 27 (not detected) EAL: Skip lcore 28 (not detected) EAL: Skip lcore 29 (not detected) EAL: Skip lcore 30 (not detected) EAL: Skip lcore 31 (not detected) EAL: Skip lcore 32 (not detected) EAL: Skip lcore 33 (not detected) EAL: Skip lcore 34 (not detected) EAL: Skip lcore 35 (not detected) EAL: Skip lcore 36 (not detected) EAL: Skip lcore 37 (not detected) EAL: Skip lcore 38 (not detected) EAL: Skip lcore 39 (not detected) EAL: Skip lcore 40 (not detected) EAL: Skip lcore 41 (not detected) EAL: Skip lcore 42 (not detected) EAL: Skip lcore 43 (not detected) EAL: Skip lcore 44 (not detected) EAL: Skip lcore 45 (not detected) EAL: Skip lcore 46 (not detected) EAL: Skip lcore 47 (not detected) EAL: Skip lcore 48 (not detected) EAL: Skip lcore 49 (not detected) EAL: Skip lcore 50 (not detected) EAL: Skip lcore 51 (not detected) EAL: Skip lcore 52 (not detected) EAL: Skip lcore 53 (not detected) EAL: Skip lcore 54 (not detected) EAL: Skip lcore 55 (not detected) EAL: Skip lcore 56 (not detected) EAL: Skip lcore 57 (not detected) EAL: Skip lcore 58 (not detected) EAL: Skip lcore 59 (not detected) EAL: Skip lcore 60 (not detected) EAL: Skip lcore 61 (not detected) EAL: Skip lcore 62 (not detected) EAL: Skip lcore 63 (not detected) EAL: Setting up memory... EAL: Ask a virtual area of 0x1073741824 bytes EAL: Virtual area found at 0x7f7dff00 (size = 0x4000) EAL: Ask a virtual area of 0x1073741824 bytes EAL: Virtual area found at 0x7f7dbee0 (size = 0x4000) EAL: Requesting 512 pages of size 2MB from socket 0 EAL: Requesting 512 pages of size 2MB from socket 1 EAL: TSC frequency is ~120 KHz EAL: Master core 0 is ready (tid=4025a840) E
[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] 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], interfaces do appear in the "probe stage" of the respective driver during RTE* initialization, but DPDK complains there are no DPDK-enabled interfaces [1]. It even happens with the examples provided [1]. Once they enter in this "zombie state", there is no way to recover them unless a reboot is performed. Attaching igb_uio -> igb -> gb_uio does not solve it either. This happens also with 1G copper ports. Any ideas? Thanks and regards marc p.s. Using 1.5.2 branch right now - [0] setup.sh Option: 10 Network devices using IGB_UIO driver :06:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused= :06:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused= Network devices using kernel driver === :08:00.1 'DH8900CC Series Gigabit Network Connection' if=eth3 drv=igb unused=igb_uio :08:00.2 'DH8900CC Series Gigabit Network Connection' if=eth5 drv=igb unused=igb_uio :08:00.3 'DH8900CC Series Gigabit Network Connection' if=eth6 drv=igb unused=igb_uio :08:00.4 'DH8900CC Series Gigabit Network Connection' if=eth7 drv=igb unused=igb_uio :09:00.0 'I350 Gigabit Network Connection' if=eth8 drv=igb unused=igb_uio *Active* :09:00.1 'I350 Gigabit Network Connection' if=eth9 drv=igb unused=igb_uio *Active* :09:00.2 'I350 Gigabit Network Connection' if=eth10 drv=igb unused=igb_uio :09:00.3 'I350 Gigabit Network Connection' if=eth11 drv=igb unused=igb_uio :85:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth2 drv=ixgbe unused=igb_uio :85:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth4 drv=ixgbe unused=igb_uio Other network devices = Enter PCI address of device to bind to IGB UIO driver: [1] l2fwd marc at bertha-dpdk:~/dpdk/examples/l2fwd/build$ sudo ./l2fwd -c 0xFF -n 2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Detected lcore 8 as core 0 on socket 1 EAL: Detected lcore 9 as core 1 on socket 1 EAL: Detected lcore 10 as core 2 on socket 1 EAL: Detected lcore 11 as core 3 on socket 1 EAL: Detected lcore 12 as core 4 on socket 1 EAL: Detected lcore 13 as core 5 on socket 1 EAL: Detected lcore 14 as core 6 on socket 1 EAL: Detected lcore 15 as core 7 on socket 1 EAL: Skip lcore 16 (not detected) EAL: Skip lcore 17 (not detected) EAL: Skip lcore 18 (not detected) EAL: Skip lcore 19 (not detected) EAL: Skip lcore 20 (not detected) EAL: Skip lcore 21 (not detected) EAL: Skip lcore 22 (not detected) EAL: Skip lcore 23 (not detected) EAL: Skip lcore 24 (not detected) EAL: Skip lcore 25 (not detected) EAL: Skip lcore 26 (not detected) EAL: Skip lcore 27 (not detected) EAL: Skip lcore 28 (not detected) EAL: Skip lcore 29 (not detected) EAL: Skip lcore 30 (not detected) EAL: Skip lcore 31 (not detected) EAL: Skip lcore 32 (not detected) EAL: Skip lcore 33 (not detected) EAL: Skip lcore 34 (not detected) EAL: Skip lcore 35 (not detected) EAL: Skip lcore 36 (not detected) EAL: Skip lcore 37 (not detected) EAL: Skip lcore 38 (not detected) EAL: Skip lcore 39 (not detected) EAL: Skip lcore 40 (not detected) EAL: Skip lcore 41 (not detected) EAL: Skip lcore 42 (not detected) EAL: Skip lcore 43 (not detected) EAL: Skip lcore 44 (not detected) EAL: Skip lcore 45 (not detected) EAL: Skip lcore 46 (not detected) EAL: Skip lcore 47 (not detected) EAL: Skip lcore 48 (not detected) EAL: Skip lcore 49 (not detected) EAL: Skip lcore 50 (not detected) EAL: Skip lcore 51 (not detected) EAL: Skip lcore 52 (not detected) EAL: Skip lcore 53 (not detected) EAL: Skip lcore 54 (not detected) EAL: Skip lcore 55 (not detected) EAL: Skip lcore 56 (not detected) EAL: Skip lcore 57 (not detected) EAL: Skip lcore 58 (not detected) EAL: Skip lcore 59 (not detected) EAL: Skip lcore 60 (not detected) EAL: Skip lcore 61 (not detected) EAL: Skip lcore 62 (not detected) EAL: Skip lcore 63 (not detected) EAL: Setting up memory... EAL: Ask a virtual area of 0x10
[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(): ixgbe_get_mac_addr_generic 9247 PMD: ixgbe_init_rx_addrs_generic(): ixgbe_init_rx_addrs_generic 9248 PMD: ixgbe_validate_mac_addr(): ixgbe_validate_mac_addr 9249 PMD: ixgbe_validate_mac_addr(): MAC address is all zeros 9250 9251 PMD: ixgbe_get_mac_addr_generic(): ixgbe_get_mac_addr_generic 9252 PMD: ixgbe_init_rx_addrs_generic(): Keeping Current RAR0 Addr =90 E2 BA 9253 PMD: ixgbe_init_rx_addrs_generic(): 00 5F E5 9254 9255 PMD: ixgbe_init_rx_addrs_generic(): Clearing RAR[1-127] 9256 9257 PMD: ixgbe_init_rx_addrs_generic(): Clearing MTA 9258 9259 PMD: ixgbe_init_uta_tables_generic(): ixgbe_init_uta_tables_generic 9260 PMD: ixgbe_init_uta_tables_generic(): Clearing UTA 9261 9262 PMD: ixgbe_get_san_mac_addr_generic(): ixgbe_get_san_mac_addr_generic 9263 PMD: ixgbe_get_san_mac_addr_offset(): ixgbe_get_san_mac_addr_offset 9264 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599 9265 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic 9266 PMD: ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic 9267 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done 9268 PMD: ixgbe_set_lan_id_multi_port_pcie(): ixgbe_set_lan_id_multi_port_pcie 9269 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599 9270 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic 9271 PMD: ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic 9272 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done 9273 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599 9274 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic 9275 PMD: ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic 9276 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done 9277 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599 9278 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic 9279 PMD: ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic 9280 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done 9281 PMD: ixgbe_validate_mac_addr(): ixgbe_validate_mac_addr 9282 PMD: ixgbe_set_rar_generic(): ixgbe_set_rar_generic 9283 PMD: ixgbe_set_vmdq_generic(): ixgbe_set_vmdq_generic 9284 PMD: ixgbe_get_wwn_prefix_generic(): ixgbe_get_wwn_prefix_generic 9285 PMD: ixgbe_read_eeprom_82599(): ixgbe_read_eeprom_82599 9286 PMD: ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic 9287 PMD: ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic 9288 PMD: ixgbe_poll_eerd_eewr_done(): ixgbe_poll_eerd_eewr_done 9289 PMD: ixgbe_get_media_type_82599(): ixgbe_get_media_type_82599 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 It turns out that the 1G ports are also using SFPs, so this may explain why in both 1g and 10g ports the same behaviour happens. Any idea? Thank you and regards marc On 25/02/14 14:00, Ananyev, Konstantin wrote: > 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-bounces at dpdk.org] On Behalf Of Marc Sune > Sent: Tuesday, February 25, 2014 12:20 PM > To: > Subject: [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], interfaces do appear in the "probe stage" of the respective driver > during RTE* initialization, but DPDK complains there are no DPDK-enabled > interfaces [1]. > > It even happens with the examples provided [1]. Once they enter in this > "zombie state", there is no way to recover them unless a reboot is performed. > Attaching igb_uio -> igb -> gb_uio does not solve it either. > This happens also with 1G copper ports. > > Any ideas? > > Thanks and regards > marc > > p.s. Using 1.5.2 branch right now > > - > > [0] setup.sh > > Option: 10 > > > Network devices using IGB_UIO driver > > :06:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' > drv=igb_uio unused= > :06:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' > drv=igb_uio unused= > > Network devices using kernel driver > === > :08:00.1 'DH8900CC Seri
[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. There was many threads discussing it but there is no definitive solution. I recommend disabling frequency scaling. But a fix would be welcome. -- Thomas
[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 of delimeter + interframe gap). Do you know what could be the problem? I am describing my experiment setup below. Setup: 1. We have Intel Xeon E5-2680 (8 cores, 2.7GHz) dual socket, with 6x10GbE Intel 82599EB dualport NICs (total of 12 ports). Machine A runs your pktgen, and Machine B runs DPDK l2fwd, unmodified. 2. We are running pktgen on Machine A with the following command: ./app/build/pktgen -c -n 4 --proc-type auto --socket-mem 1024,1024 --file-prefix pg -- -p 0xfff0 -P -m "1.0, 2.1, 3.2, 4.3, 8.4, 9.5, 10.6, 11.7, 12.8, 13.9, 14.10, 15.11" 3. We are running l2fwd on Machine B with the following command: sudo ./build/l2fwd -c 0xff0f -n 4 -- -p 0xfff Thank you very much in advance. Jun
[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_COMPILE is not set. > > Signed-off-by: Aaro Koskinen Could you explain why it's needed ? In a basic test, CC=$(CROSS)gcc in rte.vars.mk seems sufficient. Thanks -- Thomas
