[Intel-wired-lan] [PATCH S39 09/15] ice: Don't reject odd values of usecs set by user

Paul Menzel pmenzel at molgen.mpg.de
Tue Feb 11 17:21:30 UTC 2020


Dear Tony,


On 2020-01-27 09:59, Tony Nguyen wrote:
> From: Brett Creeley <brett.creeley at intel.com>
> 
> Currently if a user sets an odd [tx|rx]-usecs value through ethtool,
> the request is denied because the hardware is set to have an ITR
> granularity of 2us. This caused poor customer experience. Fix this by
> aligning to a register allowed value, which results in rounding down.
> Also, print a once per ring container type message to be clear about
> our intentions.
> 
> Also, change the ITR_TO_REG define to be the bitwise and of the ITR
> setting and the ICE_ITR_MASK. This makes the purpose of ITR_TO_REG more
> obvious.
> 
> Signed-off-by: Brett Creeley <brett.creeley at intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_ethtool.c | 49 +++++++++++++++-----
>  drivers/net/ethernet/intel/ice/ice_txrx.h    |  2 +-
>  2 files changed, 39 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> index db14ec2e0b46..ae0b63d5673d 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> @@ -3488,21 +3488,13 @@ ice_set_rc_coalesce(enum ice_container_type c_type, struct ethtool_coalesce *ec,
>  		return -EINVAL;
>  	}
>  
> -	/* hardware only supports an ITR granularity of 2us */
> -	if (coalesce_usecs % 2 != 0) {
> -		netdev_info(vsi->netdev, "Invalid value, %s-usecs must be even\n",
> -			    c_type_str);
> -		return -EINVAL;
> -	}
> -
>  	if (use_adaptive_coalesce) {
>  		rc->itr_setting |= ICE_ITR_DYNAMIC;
>  	} else {
> -		/* store user facing value how it was set */
> +		/* save the user set usecs */
>  		rc->itr_setting = coalesce_usecs;
> -		/* set to static and convert to value HW understands */
> -		rc->target_itr =
> -			ITR_TO_REG(ITR_REG_ALIGN(rc->itr_setting));
> +		/* device ITR granularity is in 2 usec increments */
> +		rc->target_itr = ITR_REG_ALIGN(rc->itr_setting);
>  	}
>  
>  	return 0;
> @@ -3595,6 +3587,30 @@ ice_is_coalesce_param_invalid(struct net_device *netdev,
>  	return 0;
>  }
>  
> +/**
> + * ice_print_if_odd_usecs - print message if user tries to set odd [tx|rx]-usecs
> + * @netdev: netdev used for print
> + * @itr_setting: previous user setting
> + * @use_adaptive_coalesce: if adaptive coalesce is enabled or being enabled
> + * @coalesce_usecs: requested value of [tx|rx]-usecs
> + * @c_type_str: either "rx" or "tx" to match user set field of [tx|rx]-usecs

Why `c_type_str`? What does it mean?

> + */
> +static void
> +ice_print_if_odd_usecs(struct net_device *netdev, u16 itr_setting,
> +		       u32 use_adaptive_coalesce, u32 coalesce_usecs,
> +		       const char *c_type_str)
> +{
> +	if (use_adaptive_coalesce)
> +		return;

Why not check that before calling the function and not passing the it to this
one.

> +
> +	itr_setting = ITR_TO_REG(itr_setting);
> +
> +	if (itr_setting != coalesce_usecs && (coalesce_usecs % 2))
> +		netdev_info(netdev, "User set %s-usecs to %d, device only supports even values. Rounding down and attempting to set %s-usecs to %d\n",
> +			    c_type_str, coalesce_usecs, c_type_str,
> +			    ITR_REG_ALIGN(coalesce_usecs));
> +}
> +
>  /**
>   * __ice_set_coalesce - set ITR/INTRL values for the device
>   * @netdev: pointer to the netdev associated with this query
> @@ -3615,8 +3631,19 @@ __ice_set_coalesce(struct net_device *netdev, struct ethtool_coalesce *ec,
>  		return -EINVAL;
>  
>  	if (q_num < 0) {
> +		struct ice_q_vector *q_vector = vsi->q_vectors[0];
>  		int v_idx;
>  
> +		if (q_vector) {

Why not check for `(coalesce_usecs % 2)` here already?

> +			ice_print_if_odd_usecs(netdev, q_vector->rx.itr_setting,
> +					       ec->use_adaptive_rx_coalesce,
> +					       ec->rx_coalesce_usecs, "rx");
> +
> +			ice_print_if_odd_usecs(netdev, q_vector->tx.itr_setting,
> +					       ec->use_adaptive_tx_coalesce,
> +					       ec->tx_coalesce_usecs, "tx");
> +		}
> +

I do not know of such a construct in the rest of the Linux kernel. Is there
a better way to achieve your goal?

>  		ice_for_each_q_vector(vsi, v_idx) {
>  			/* In some cases if DCB is configured the num_[rx|tx]q
>  			 * can be less than vsi->num_q_vectors. This check
> diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.h b/drivers/net/ethernet/intel/ice/ice_txrx.h
> index a86270696df1..3e3cc2599824 100644
> --- a/drivers/net/ethernet/intel/ice/ice_txrx.h
> +++ b/drivers/net/ethernet/intel/ice/ice_txrx.h
> @@ -222,7 +222,7 @@ enum ice_rx_dtype {
>  #define ICE_ITR_GRAN_S		1	/* ITR granularity is always 2us */
>  #define ICE_ITR_GRAN_US		BIT(ICE_ITR_GRAN_S)
>  #define ICE_ITR_MASK		0x1FFE	/* ITR register value alignment mask */
> -#define ITR_REG_ALIGN(setting)	__ALIGN_MASK(setting, ~ICE_ITR_MASK)
> +#define ITR_REG_ALIGN(setting)	((setting) & ICE_ITR_MASK)
>  
>  #define ICE_ITR_ADAPTIVE_MIN_INC	0x0002
>  #define ICE_ITR_ADAPTIVE_MIN_USECS	0x0002
> 


Kind regards,

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20200211/a4501f0f/attachment-0001.p7s>


More information about the Intel-wired-lan mailing list