13/10/2020 10:40, 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 <tho...@monjalon.net>
> >>> Reviewed-by: Liron Himi <lir...@marvell.com>
> >>> Acked-by: Stephen Hemminger <step...@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?
Yes you're right.
> IMHO it would be nice to make it uniform across ethdev API.
Yes, do you want to make the patch to change other occurences to ENODEV?
> >>> 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.
Yes it's an elegant pattern :)
