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-boun...@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 ND and
treat it as read-only (the only exception: ixgbe/ixgbe_osdep.h).
Otherwise it might become quite messy pretty quickly.
To overcome some problems or shortcomings in ND code people usually use
wrappers at the upper layer - that way was implemented bypass support,
loopback support, plus some other fixes (reported number of queues per VF,
etc).
I wonder couldn't your fix also be pushed to the upper layer (in ixgbe_ethdev.c
or something)?
Thanks
Konstantin
-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
Sent: Wednesday, February 19, 2014 4:52 PM
To: Ananyev, Konstantin
Cc: Didier Pallard; dev at dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked
semaphores on initialization
19/02/2014 13:41, Ananyev, Konstantin:
> Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe
> directory untouched? Those files are derived directly from the BSD
> driver baseline, and any changes will make future merges of newer code
> more challenging. The changes should be limited to files in the
> librte_pmd_ixgbe directory (and ethdev). Thanks
Please, could you send an url to the BSD driver baseline ?
By the way, git is very good at rebasing such patches.
And if the fix is good, it should be applied on the baseline.
Refusing a fix without alternative is not an option.
--
Thomas
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263 Business address: Dromore House, East Park, Shannon,
Co. Clare
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
