diff mbox

[dpdk-dev] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id

Message ID 1461943396-7094-1-git-send-email-mauricio.vasquezbernal@studenti.polito.it (mailing list archive)
State Changes Requested, archived
Delegated to: Thomas Monjalon
Headers

Commit Message

Mauricio Vasquez B April 29, 2016, 3:23 p.m. UTC 
  The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
to check if a port id is valid or not. This commit makes use of it in
some new parts of the code.

Signed-off-by: Mauricio Vasquez B <mauricio.vasquezbernal@studenti.polito.it>
---
 lib/librte_ether/rte_ethdev.c | 39 +++++++++------------------------------
 1 file changed, 9 insertions(+), 30 deletions(-)

Comments

Thomas Monjalon May 13, 2016, 4:20 p.m. UTC | #1 
2016-04-29 17:23, Mauricio Vasquez B:
> The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> to check if a port id is valid or not. This commit makes use of it in
> some new parts of the code.

There are other occurences:
	rte_eth_dev_socket_id
	rte_eth_add_rx_callback
	rte_eth_add_tx_callback
	rte_eth_remove_rx_callback
	rte_eth_remove_tx_callback
I think it could be done also in examples/ethtool/lib.
Mauricio Vasquez B May 17, 2016, 8:02 p.m. UTC | #2 
Hello Thomas,



On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> 2016-04-29 17:23, Mauricio Vasquez B:
> > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > to check if a port id is valid or not. This commit makes use of it in
> > some new parts of the code.
>
> There are other occurences:
>         rte_eth_dev_socket_id
>
I missed it.

>         rte_eth_add_rx_callback
>         rte_eth_add_tx_callback
>         rte_eth_remove_rx_callback
>         rte_eth_remove_tx_callback
>
The macro can not be used on those ones because they set the rte_errno
variable before returning.

> I think it could be done also in examples/ethtool/lib.
>
I'll send v2 including that one.

Mauricio V,
Thomas Monjalon May 18, 2016, 8:15 a.m. UTC | #3 
2016-05-17 22:02, Mauricio Vásquez:
> On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
> wrote:
> > 2016-04-29 17:23, Mauricio Vasquez B:
> > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > to check if a port id is valid or not. This commit makes use of it in
> > > some new parts of the code.
> >
> > There are other occurences:
> >         rte_eth_dev_socket_id
> >
> I missed it.
> 
> >         rte_eth_add_rx_callback
> >         rte_eth_add_tx_callback
> >         rte_eth_remove_rx_callback
> >         rte_eth_remove_tx_callback
> >
> The macro can not be used on those ones because they set the rte_errno
> variable before returning.

It may be a good idea to set rte_errno to EINVAL in these macros.

Generally speaking, rte_errno is not used a lot currently.
Mauricio Vasquez B May 18, 2016, 2:41 p.m. UTC | #4 
On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <thomas.monjalon@6wind.com
> wrote:

> 2016-05-17 22:02, Mauricio Vásquez:
> > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> thomas.monjalon@6wind.com>
> > wrote:
> > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > to check if a port id is valid or not. This commit makes use of it in
> > > > some new parts of the code.
> > >
> > > There are other occurences:
> > >         rte_eth_dev_socket_id
> > >
> > I missed it.
> >
> > >         rte_eth_add_rx_callback
> > >         rte_eth_add_tx_callback
> > >         rte_eth_remove_rx_callback
> > >         rte_eth_remove_tx_callback
> > >
> > The macro can not be used on those ones because they set the rte_errno
> > variable before returning.
>
> It may be a good idea to set rte_errno to EINVAL in these macros.
>
> Generally speaking, rte_errno is not used a lot currently.


I noticed that both EINVAL and ENODEV are used. I think that returning
ENODEV and setting rte_errno to EINVAL would be strange, what do you think
about always using ENODEV?
Thomas Monjalon May 18, 2016, 3:01 p.m. UTC | #5 
2016-05-18 16:41, Mauricio Vásquez:
> On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <thomas.monjalon@6wind.com
> > wrote:
> 
> > 2016-05-17 22:02, Mauricio Vásquez:
> > > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> > thomas.monjalon@6wind.com>
> > > wrote:
> > > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > > to check if a port id is valid or not. This commit makes use of it in
> > > > > some new parts of the code.
> > > >
> > > > There are other occurences:
> > > >         rte_eth_dev_socket_id
> > > >
> > > I missed it.
> > >
> > > >         rte_eth_add_rx_callback
> > > >         rte_eth_add_tx_callback
> > > >         rte_eth_remove_rx_callback
> > > >         rte_eth_remove_tx_callback
> > > >
> > > The macro can not be used on those ones because they set the rte_errno
> > > variable before returning.
> >
> > It may be a good idea to set rte_errno to EINVAL in these macros.
> >
> > Generally speaking, rte_errno is not used a lot currently.
> 
> 
> I noticed that both EINVAL and ENODEV are used. I think that returning
> ENODEV and setting rte_errno to EINVAL would be strange, what do you think
> about always using ENODEV?

Why EINVAL is used?
Why not using retval to set errno?
I feel ENODEV would be better but it is an API change, so we should discuss
it later for another patch.
Mauricio Vasquez B May 18, 2016, 3:25 p.m. UTC | #6 
On Wed, May 18, 2016 at 5:01 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> 2016-05-18 16:41, Mauricio Vásquez:
> > On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <
> thomas.monjalon@6wind.com
> > > wrote:
> >
> > > 2016-05-17 22:02, Mauricio Vásquez:
> > > > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> > > thomas.monjalon@6wind.com>
> > > > wrote:
> > > > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > > > to check if a port id is valid or not. This commit makes use of
> it in
> > > > > > some new parts of the code.
> > > > >
> > > > > There are other occurences:
> > > > >         rte_eth_dev_socket_id
> > > > >
> > > > I missed it.
> > > >
> > > > >         rte_eth_add_rx_callback
> > > > >         rte_eth_add_tx_callback
> > > > >         rte_eth_remove_rx_callback
> > > > >         rte_eth_remove_tx_callback
> > > > >
> > > > The macro can not be used on those ones because they set the
> rte_errno
> > > > variable before returning.
> > >
> > > It may be a good idea to set rte_errno to EINVAL in these macros.
> > >
> > > Generally speaking, rte_errno is not used a lot currently.
> >
> >
> > I noticed that both EINVAL and ENODEV are used. I think that returning
> > ENODEV and setting rte_errno to EINVAL would be strange, what do you
> think
> > about always using ENODEV?
>
> Why EINVAL is used?
>
Why not using retval to set errno?
>

If we do it, the macro could no be used in
 rte_eth_dev_socket_id
 rte_eth_dev_get_device_type
 rte_eth_add_rx_callback
 rte_eth_add_tx_callback
 rte_eth_remove_rx_callback
 rte_eth_remove_tx_callback
as they do not return an error number.

I feel ENODEV would be better but it is an API change, so we should discuss
> it later for another patch.
>

I agree
Thomas Monjalon May 18, 2016, 3:43 p.m. UTC | #7 
2016-05-18 17:25, Mauricio Vásquez:
> On Wed, May 18, 2016 at 5:01 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
> wrote:
> 
> > 2016-05-18 16:41, Mauricio Vásquez:
> > > On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <
> > thomas.monjalon@6wind.com
> > > > wrote:
> > >
> > > > 2016-05-17 22:02, Mauricio Vásquez:
> > > > > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> > > > thomas.monjalon@6wind.com>
> > > > > wrote:
> > > > > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
> > > > > > > to check if a port id is valid or not. This commit makes use of
> > it in
> > > > > > > some new parts of the code.
> > > > > >
> > > > > > There are other occurences:
> > > > > >         rte_eth_dev_socket_id
> > > > > >
> > > > > I missed it.
> > > > >
> > > > > >         rte_eth_add_rx_callback
> > > > > >         rte_eth_add_tx_callback
> > > > > >         rte_eth_remove_rx_callback
> > > > > >         rte_eth_remove_tx_callback
> > > > > >
> > > > > The macro can not be used on those ones because they set the
> > rte_errno
> > > > > variable before returning.
> > > >
> > > > It may be a good idea to set rte_errno to EINVAL in these macros.
> > > >
> > > > Generally speaking, rte_errno is not used a lot currently.
> > >
> > >
> > > I noticed that both EINVAL and ENODEV are used. I think that returning
> > > ENODEV and setting rte_errno to EINVAL would be strange, what do you
> > think
> > > about always using ENODEV?
> >
> > Why EINVAL is used?
> >
> Why not using retval to set errno?
> >
> 
> If we do it, the macro could no be used in
>  rte_eth_dev_socket_id
>  rte_eth_dev_get_device_type
>  rte_eth_add_rx_callback
>  rte_eth_add_tx_callback
>  rte_eth_remove_rx_callback
>  rte_eth_remove_tx_callback
> as they do not return an error number.

So you should not set errno in the existing macro.
But you can create a new macro RTE_ETH_VALID_PORTID_OR_ERRNO_RET
for these functions.

> I feel ENODEV would be better but it is an API change, so we should discuss
> > it later for another patch.

It looks to be really needed to have an unique kind of error interface to
clean all this mess.
Mauricio Vasquez B May 18, 2016, 7:14 p.m. UTC | #8 
On Wed, May 18, 2016 at 5:43 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> 2016-05-18 17:25, Mauricio Vásquez:
> > On Wed, May 18, 2016 at 5:01 PM, Thomas Monjalon <
> thomas.monjalon@6wind.com>
> > wrote:
> >
> > > 2016-05-18 16:41, Mauricio Vásquez:
> > > > On Wed, May 18, 2016 at 10:15 AM, Thomas Monjalon <
> > > thomas.monjalon@6wind.com
> > > > > wrote:
> > > >
> > > > > 2016-05-17 22:02, Mauricio Vásquez:
> > > > > > On Fri, May 13, 2016 at 6:20 PM, Thomas Monjalon <
> > > > > thomas.monjalon@6wind.com>
> > > > > > wrote:
> > > > > > > 2016-04-29 17:23, Mauricio Vasquez B:
> > > > > > > > The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some
> places
> > > > > > > > to check if a port id is valid or not. This commit makes use
> of
> > > it in
> > > > > > > > some new parts of the code.
> > > > > > >
> > > > > > > There are other occurences:
> > > > > > >         rte_eth_dev_socket_id
> > > > > > >
> > > > > > I missed it.
> > > > > >
> > > > > > >         rte_eth_add_rx_callback
> > > > > > >         rte_eth_add_tx_callback
> > > > > > >         rte_eth_remove_rx_callback
> > > > > > >         rte_eth_remove_tx_callback
> > > > > > >
> > > > > > The macro can not be used on those ones because they set the
> > > rte_errno
> > > > > > variable before returning.
> > > > >
> > > > > It may be a good idea to set rte_errno to EINVAL in these macros.
> > > > >
> > > > > Generally speaking, rte_errno is not used a lot currently.
> > > >
> > > >
> > > > I noticed that both EINVAL and ENODEV are used. I think that
> returning
> > > > ENODEV and setting rte_errno to EINVAL would be strange, what do you
> > > think
> > > > about always using ENODEV?
> > >
> > > Why EINVAL is used?
> > >
> > Why not using retval to set errno?
> > >
> >
> > If we do it, the macro could no be used in
> >  rte_eth_dev_socket_id
> >  rte_eth_dev_get_device_type
> >  rte_eth_add_rx_callback
> >  rte_eth_add_tx_callback
> >  rte_eth_remove_rx_callback
> >  rte_eth_remove_tx_callback
> > as they do not return an error number.
>
> So you should not set errno in the existing macro.
> But you can create a new macro RTE_ETH_VALID_PORTID_OR_ERRNO_RET
> for these functions.
>
> I realized that RTE_ETH_VALID_PORTID_OR_ERR_RET can be used also in
rte_eth_remove_rx_callback and rte_eth_remove_tx_callback.

Personally I think it is not worthy to create a macro just for the two
missing functions.


> > I feel ENODEV would be better but it is an API change, so we should
> discuss
> > > it later for another patch.
>
> It looks to be really needed to have an unique kind of error interface to
> clean all this mess.
>
diff mbox

Patch

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..bf9d4d2 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -383,8 +383,8 @@  rte_eth_dev_count(void)
 static enum rte_eth_dev_type
 rte_eth_dev_get_device_type(uint8_t port_id)
 {
-	if (!rte_eth_dev_is_valid_port(port_id))
-		return RTE_ETH_DEV_UNKNOWN;
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, RTE_ETH_DEV_UNKNOWN);
+
 	return rte_eth_devices[port_id].dev_type;
 }
 
@@ -479,10 +479,7 @@  rte_eth_dev_is_detachable(uint8_t port_id)
 {
 	uint32_t dev_flags;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-		return -EINVAL;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
 	switch (rte_eth_devices[port_id].data->kdrv) {
 	case RTE_KDRV_IGB_UIO:
@@ -1994,10 +1991,7 @@  rte_eth_dev_rss_reta_query(uint8_t port_id,
 	struct rte_eth_dev *dev;
 	int ret;
 
-	if (port_id >= nb_ports) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	/* Check mask bits */
 	ret = rte_eth_check_reta_mask(reta_conf, reta_size);
@@ -2641,10 +2635,7 @@  rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int op, void *data)
 	uint16_t qid;
 	int rc;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	dev = &rte_eth_devices[port_id];
 	intr_handle = &dev->pci_dev->intr_handle;
@@ -2699,10 +2690,7 @@  rte_eth_dev_rx_intr_ctl_q(uint8_t port_id, uint16_t queue_id,
 	struct rte_intr_handle *intr_handle;
 	int rc;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	dev = &rte_eth_devices[port_id];
 	if (queue_id >= dev->data->nb_rx_queues) {
@@ -2734,10 +2722,7 @@  rte_eth_dev_rx_intr_enable(uint8_t port_id,
 {
 	struct rte_eth_dev *dev;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	dev = &rte_eth_devices[port_id];
 
@@ -2751,10 +2736,7 @@  rte_eth_dev_rx_intr_disable(uint8_t port_id,
 {
 	struct rte_eth_dev *dev;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	dev = &rte_eth_devices[port_id];
 
@@ -3284,10 +3266,7 @@  rte_eth_dev_get_dcb_info(uint8_t port_id,
 {
 	struct rte_eth_dev *dev;
 
-	if (!rte_eth_dev_is_valid_port(port_id)) {
-		RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-		return -ENODEV;
-	}
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 
 	dev = &rte_eth_devices[port_id];
 	memset(dcb_info, 0, sizeof(struct rte_eth_dcb_info));