[dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Monday, March 6, 2017 4:15 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com;
> jerin.jacob at caviumnetworks.com;
> balasubramanian.manoharan at cavium.com; hemant.agrawal at nxp.com;
> shreyansh.jain at nxp.com
> Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler
> API
> 
> On Sat,  4 Mar 2017 01:10:20 +0000
> Cristian Dumitrescu <cristian.dumitrescu at intel.com> wrote:
> 
> > +/* Get generic traffic manager operations structure from a port. */
> > +const struct rte_tm_ops *
> > +rte_tm_ops_get(uint8_t port_id, struct rte_tm_error *error)
> > +{
> > +	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > +	const struct rte_tm_ops *ops;
> > +
> > +	if (!rte_eth_dev_is_valid_port(port_id)) {
> > +		rte_tm_error_set(error,
> > +			ENODEV,
> > +			RTE_TM_ERROR_TYPE_UNSPECIFIED,
> > +			NULL,
> > +			rte_strerror(ENODEV));
> > +		return NULL;
> > +	}
> > +
> > +	if ((dev->dev_ops->cap_ops_get == NULL) ||
> > +		(dev->dev_ops->cap_ops_get(dev,
> RTE_ETH_CAPABILITY_TM,
> > +		&ops) != 0) || (ops == NULL)) {
> > +		rte_tm_error_set(error,
> > +			ENOSYS,
> > +			RTE_TM_ERROR_TYPE_UNSPECIFIED,
> > +			NULL,
> > +			rte_strerror(ENOSYS));
> > +		return NULL;
> > +	}
> > +
> > +	return ops;
> > +}
> 
> Why are you introducing yet another version of errno? There already is
> rte_errno for RTE specific errors.

Have you looked at rte_flow? It is already doing this, and people asked me to follow the same approach here for domain specific error codes.

Look at Jerin's feedback on RFC here: http://www.dpdk.org/ml/archives/dev/2017-January/054484.html
"IMO, We need an explicit error number to differentiate the configuration error due do Ethernet port has been started.
The recent rte_flow spec has own error codes to get more visibility on the failure, so that application can choose better attributes for configuring."

I agreed it is a good idea, as it gives you a precise indication on what exactly went wrong. A generic error code of EBUSY needs to be complemented by a second level of library-specific error details. Note that we are also setting rte_errno.