[dpdk-dev,RFC,09/14] sfc: use new rte_eth_link helpers

  Use the new API (_rte_eth_link_update) to handle link status update.
ALso fixes a bug where this driver was not returning -1 when link status changed.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/net/sfc/sfc_ethdev.c | 27 +++++++--------------------
 drivers/net/sfc/sfc_ev.c     | 23 ++++-------------------
 2 files changed, 11 insertions(+), 39 deletions(-)
  

On 07/14/2017 09:30 PM, Stephen Hemminger wrote:
> Use the new API (_rte_eth_link_update) to handle link status update.
> ALso fixes a bug where this driver was not returning -1 when link status changed.

It is really good that you raise it, since:
  -  as far as I can see the return value of the link_update is never used
  - return value is not described and it is unclear what is meant by "link
     status changed" since initial point is unspecified

We have interpreted link status change as change in data->dev_link
made in the current execution flow, but not in parallel execution flow.

>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>   drivers/net/sfc/sfc_ethdev.c | 27 +++++++--------------------
>   drivers/net/sfc/sfc_ev.c     | 23 ++++-------------------
>   2 files changed, 11 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
> index 6b06f08f7c1a..f0a40ad06f23 100644
> --- a/drivers/net/sfc/sfc_ethdev.c
> +++ b/drivers/net/sfc/sfc_ethdev.c
> @@ -231,22 +231,12 @@ static int
>   sfc_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
>   {
>   	struct sfc_adapter *sa = dev->data->dev_private;
> -	struct rte_eth_link *dev_link = &dev->data->dev_link;
> -	struct rte_eth_link old_link;
>   	struct rte_eth_link current_link;
>   
>   	sfc_log_init(sa, "entry");
>   
> -retry:
> -	EFX_STATIC_ASSERT(sizeof(*dev_link) == sizeof(rte_atomic64_t));
> -	*(int64_t *)&old_link = rte_atomic64_read((rte_atomic64_t *)dev_link);
> -
>   	if (sa->state != SFC_ADAPTER_STARTED) {
>   		sfc_port_link_mode_to_info(EFX_LINK_UNKNOWN, &current_link);
> -		if (!rte_atomic64_cmpset((volatile uint64_t *)dev_link,
> -					 *(uint64_t *)&old_link,
> -					 *(uint64_t *)&current_link))
> -			goto retry;
>   	} else if (wait_to_complete) {
>   		efx_link_mode_t link_mode;
>   
> @@ -254,21 +244,18 @@ sfc_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
>   			link_mode = EFX_LINK_UNKNOWN;
>   		sfc_port_link_mode_to_info(link_mode, &current_link);
>   
> -		if (!rte_atomic64_cmpset((volatile uint64_t *)dev_link,
> -					 *(uint64_t *)&old_link,
> -					 *(uint64_t *)&current_link))
> -			goto retry;
>   	} else {
>   		sfc_ev_mgmt_qpoll(sa);
> -		*(int64_t *)&current_link =
> -			rte_atomic64_read((rte_atomic64_t *)dev_link);
> +		_rte_eth_link_read(dev, &current_link);
>   	}
>   
> -	if (old_link.link_status != current_link.link_status)
> -		sfc_info(sa, "Link status is %s",
> -			 current_link.link_status ? "UP" : "DOWN");
> +	if (_rte_eth_link_update(dev, &current_link) == 0)
> +		return 0;
> +
> +	sfc_info(sa, "Link status is %s",
> +		 current_link.link_status ? "UP" : "DOWN");
>   
> -	return old_link.link_status == current_link.link_status ? 0 : -1;
> +	return -1;
>   }
>   
>   static void
> diff --git a/drivers/net/sfc/sfc_ev.c b/drivers/net/sfc/sfc_ev.c
> index a16dc27b380e..fc88baef0ef3 100644
> --- a/drivers/net/sfc/sfc_ev.c
> +++ b/drivers/net/sfc/sfc_ev.c
> @@ -404,29 +404,14 @@ sfc_ev_link_change(void *arg, efx_link_mode_t link_mode)
>   {
>   	struct sfc_evq *evq = arg;
>   	struct sfc_adapter *sa = evq->sa;
> -	struct rte_eth_link *dev_link = &sa->eth_dev->data->dev_link;
>   	struct rte_eth_link new_link;
> -	uint64_t new_link_u64;
> -	uint64_t old_link_u64;
> -
> -	EFX_STATIC_ASSERT(sizeof(*dev_link) == sizeof(rte_atomic64_t));
>   
>   	sfc_port_link_mode_to_info(link_mode, &new_link);
> +	if (_rte_eth_link_update(sa->eth_dev, &new_link) == 0)
> +		return B_FALSE;

It means that change of link speed without link down (not sure that it is
possible, but still) will happen without link status interrupt. May be link
status is about UP/DOWN only, but I'm not sure that it is a good limitation.

At least it is not what we want in initial implementation.

> -	new_link_u64 = *(uint64_t *)&new_link;
> -	do {
> -		old_link_u64 = rte_atomic64_read((rte_atomic64_t *)dev_link);
> -		if (old_link_u64 == new_link_u64)
> -			break;
> -
> -		if (rte_atomic64_cmpset((volatile uint64_t *)dev_link,
> -					old_link_u64, new_link_u64)) {
> -			evq->sa->port.lsc_seq++;
> -			break;
> -		}
> -	} while (B_TRUE);
> -
> -	return B_FALSE;
> +	evq->sa->port.lsc_seq++;
> +	return B_TRUE;
>   }
>   
>   static const efx_ev_callbacks_t sfc_ev_callbacks = {
  

On Sun, 16 Jul 2017 16:48:50 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:

> On 07/14/2017 09:30 PM, Stephen Hemminger wrote:
> > Use the new API (_rte_eth_link_update) to handle link status update.
> > ALso fixes a bug where this driver was not returning -1 when link status changed.  
> 
> It is really good that you raise it, since:
>   -  as far as I can see the return value of the link_update is never used
>   - return value is not described and it is unclear what is meant by "link
>      status changed" since initial point is unspecified
> 
> We have interpreted link status change as change in data->dev_link
> made in the current execution flow, but not in parallel execution flow.

All drivers must do the same thing. Private interpretation is not good.
  

On 07/17/2017 07:02 PM, Stephen Hemminger wrote:
> On Sun, 16 Jul 2017 16:48:50 +0300
> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
>
>> On 07/14/2017 09:30 PM, Stephen Hemminger wrote:
>>> Use the new API (_rte_eth_link_update) to handle link status update.
>>> ALso fixes a bug where this driver was not returning -1 when link status changed.
>> It is really good that you raise it, since:
>>    -  as far as I can see the return value of the link_update is never used
>>    - return value is not described and it is unclear what is meant by "link
>>       status changed" since initial point is unspecified
>>
>> We have interpreted link status change as change in data->dev_link
>> made in the current execution flow, but not in parallel execution flow.
> All drivers must do the same thing. Private interpretation is not good.

Definitely agree, but to do so, API documentation must clearly define
what is required. It is especially pity that all these "fixes" and 
complexity
is just a waste of time since return value is actually never used.