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

didier.pallard didier.pallard at 6wind.com
Mon Feb 24 15:19:00 CET 2014


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 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.monjalon at 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.
>
>


-- 
Didier PALLARD
6WIND
Software Engineer

Tel: +33 1 39 30 92 46
Mob: +33 6 49 11 40 14
Fax: +33 1 39 30 92 11
didier.pallard at 6wind.com
www.6wind.com

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to 6WIND. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné à son ou ses destinataires. Il contient des informations confidentielles qui sont la propriété de 6WIND. Toute révélation, distribution ou copie des informations qu'il contient est strictement interdite. Si vous avez reçu ce message par erreur, veuillez immédiatement le signaler à l'émetteur et détruire toutes les données reçues



More information about the dev mailing list