[dpdk-dev] [PATCH v4 3/3] ethdev: allow close function to return an error

[Andrew Rybchenko]

On 10/6/20 1:57 PM, Thomas Monjalon wrote:
> 06/10/2020 11:43, Ferruh Yigit:
>> On 10/5/2020 6:08 PM, Thomas Monjalon wrote:
>>> The API function rte_eth_dev_close() was returning void.
>>> The return type is changed to int for notifying of errors.
>>>
>>> If an error happens during a close operation,
>>> the status of the port is undefined,
>>> a maximum of resources having been freed.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas at monjalon.net>
>>> Reviewed-by: Liron Himi <lironh at marvell.com>
>>> Acked-by: Stephen Hemminger <stephen at networkplumber.org>
>>
>> <...>
>>
>>> -void
>>> +int
>>>   rte_eth_dev_close(uint16_t port_id)
>>>   {
>>>   	struct rte_eth_dev *dev;
>>> +	int firsterr, binerr;
>>> +	int *lasterr = &firsterr;
>>>   
>>> -	RTE_ETH_VALID_PORTID_OR_RET(port_id);
>>> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);

Shouldn't it be -ENODEV in fact?
IMHO it would be nice to make it uniform across ethdev API.

>>>   	dev = &rte_eth_devices[port_id];
>>>   
>>> -	RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_close);
>>> -	(*dev->dev_ops->dev_close)(dev);
>>> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_close, -ENOTSUP);
>>> +	*lasterr = (*dev->dev_ops->dev_close)(dev);
>>> +	if (*lasterr != 0)
>>> +		lasterr = &binerr;
>>>   
>>>   	rte_ethdev_trace_close(port_id);
>>> -	rte_eth_dev_release_port(dev);
>>> +	*lasterr = rte_eth_dev_release_port(dev);
>>> +
>>> +	return firsterr;
>>>   }
>>
>> This may be personal taste but above error handling looks like unnecessary 
>> complex, what do you think something like below:
>>
>> close_err = (*dev->dev_ops->dev_close)(dev);
>> release_err = rte_eth_dev_release_port(dev);
>> return close_err ? close_err : release_err;
> 
> This is what I did first. Then thought about this "elegant" handling.
> The pointer solution is just one more line and is more future proof.
> 
> I'm fine with any choice. Andrew?
> 

Hm, really hard to make a choice. I tend to choose Thomas's
version. Yes, I agree that it is a bit over-complicated in
this particular case, but thoughts to be future-proof
overweight for me. Plus it adds a pattern on how to handle
such cases in the future.