Re: [PATCH RFC v1 net-next 5/5] net: ena: Advertise ETHTOOL_RING_USE_TX_PUSH_BUF_LEN support

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 1 Mar 2023 20:02:13 +0200 Shay Agroskin wrote:
> -static const struct ethtool_ops ena_ethtool_ops = {
> +static struct ethtool_ops ena_ethtool_ops = {
>  	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
>  				     ETHTOOL_COALESCE_USE_ADAPTIVE_RX,
>  	.get_link_ksettings	= ena_get_link_ksettings,
> @@ -967,8 +967,18 @@ static const struct ethtool_ops ena_ethtool_ops = {
>  	.get_ts_info            = ethtool_op_get_ts_info,
>  };
>  
> -void ena_set_ethtool_ops(struct net_device *netdev)
> +void ena_set_ethtool_ops(struct ena_adapter *adapter)
>  {
> +	struct net_device *netdev = adapter->netdev;
> +
> +	ena_ethtool_ops.supported_ring_params = 0;
> +	if (adapter->ena_dev->tx_mem_queue_type ==
> +	    ENA_ADMIN_PLACEMENT_POLICY_HOST)
> +		goto no_llq_supported;
> +
> +	ena_ethtool_ops.supported_ring_params |= ETHTOOL_RING_USE_TX_PUSH_BUF_LEN;
> +
> +no_llq_supported:
>  	netdev->ethtool_ops = &ena_ethtool_ops;
>  }

Don't update the global structures based on caps of a single device.
The opt-in is to declare that the driver will act on the value, doesn't
necessarily mean that given device can support the feature.
Leave ETHTOOL_RING_USE_TX_PUSH_BUF_LEN always set and error out
appropriately in ena_set_ringparam().

Option #2 is to refactor the supported features into a struct
and add a callback for driver to "fix up" the caps at request time.
But that'd touch a lot of drivers.