Re: [PATCH net-next 1/1] sfc: Allow driver to cope with a lower number of VIs than it needs for RSS

2015-08-28 Thread David Miller
From: Shradha Shah 
Date: Fri, 28 Aug 2015 10:55:42 +0100

> Previously, the driver would refuse to load if it couldn't secure
> enough VIs from the MC to fulfill its RSS requirements.
> This was causing probe to fail on later functions in
> configurations where we'd run out of VIs, such as having many
> VFs.
> 
> This change allows the driver to load with fewer VIs, down to a
> minimum of 2. A warning will be printed saying that RSS
> requirements were not met, possibly affecting performance.
> 
> efx->max_tx_channels needs to be set to avoid going down the
> failure path in efx_probe_nic() immediately in the loop after the
> probe() NIC-type function.
> Also, Set rc=ENOSPC when bombing out of efx_probe_nic due to lack
> of VIs.
> 
> Signed-off-by: Shradha Shah 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH net-next 1/1] sfc: Allow driver to cope with a lower number of VIs than it needs for RSS

2015-08-25 Thread David Miller
From: Shradha Shah 
Date: Fri, 21 Aug 2015 10:43:51 +0100

> @@ -115,7 +115,7 @@ static struct workqueue_struct *reset_workqueue;
>   *
>   * This is only used in MSI-X interrupt mode
>   */
> -static bool separate_tx_channels;
> +bool separate_tx_channels;
 ...
> @@ -35,6 +35,7 @@ void efx_xmit_done(struct efx_tx_queue *tx_queue, unsigned 
> int index);
>  int efx_setup_tc(struct net_device *net_dev, u8 num_tc);
>  unsigned int efx_tx_max_skb_descs(struct efx_nic *efx);
>  extern unsigned int efx_piobuf_size;
> +extern bool separate_tx_channels;

Once you put this into the global namespace, you should prefix it
with "efx_*" or similar to avoid namespace pollution issues.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html