[dpdk-dev] [RFC 0/2] add new fields to rte_eth_dev_info structure

[dpdk-dev] [RFC 0/2] add new fields to rte_eth_dev_info structure

[Reshma Pattan]

New fields nb_rx_queues and nb_tx_queues are added to rte_eth_dev_info structure.
Changes to API rte_eth_dev_info_get() are done to update these new fields to rte_eth_dev_info object.

These changes are ABI breakage and we are late to announce deprecation notice for 16.07,
however the rte_ether library is already subject to a deprecation notice in 16.07.

Reshma Pattan (2):
  doc: announce ABI change for rte_eth_dev_info structure
  librte_ether: add new fields to rte_eth_dev_info struct

 doc/guides/rel_notes/deprecation.rst | 6 ++++++
 lib/librte_ether/rte_ethdev.c        | 2 ++
 lib/librte_ether/rte_ethdev.h        | 3 +++
 3 files changed, 11 insertions(+)

-- 
2.5.0

[dpdk-dev] [RFC 1/2] doc: announce ABI change for rte_eth_dev_info structure

[Reshma Pattan]

New fields nb_rx_queues and nb_tx_queues will be added to
rte_eth_dev_info structure.
Changes to API rte_eth_dev_info_get() will be done to update
these new fields to rte_eth_dev_info object.

Signed-off-by:reshma Pattan<reshma.pattan@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 327fc2b..78cedb7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -90,3 +90,9 @@ Deprecation Notices
   a handle, like the way kernel exposes an fd to user for locating a
   specific file, and to keep all major structures internally, so that
   we are likely to be free from ABI violations in future.
+
+* A librte_ether public structure ``rte_eth_dev_info`` will be changed in 16.07.
+  The proposed change will add new parameters ``nb_rx_queues``, ``nb_tx_queues``
+  to the structure. These are the number of queues configured by software.
+  Modification to definition of ``rte_eth_dev_info_get()`` will be done
+  to update new parameters to ``rte_eth_dev_info`` object.
-- 
2.5.0

Re: [dpdk-dev] [RFC 1/2] doc: announce ABI change for rte_eth_dev_info structure

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, April 14, 2016 10:45 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [RFC 1/2] doc: announce ABI change for
> rte_eth_dev_info structure
> 
> New fields nb_rx_queues and nb_tx_queues will be added to rte_eth_dev_info
> structure.
> Changes to API rte_eth_dev_info_get() will be done to update these new
> fields to rte_eth_dev_info object.
> 
> Signed-off-by:reshma Pattan<reshma.pattan@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [dpdk-dev] [RFC 1/2] doc: announce ABI change for rte_eth_dev_info structure

[Thomas Monjalon]

2016-04-14 10:44, Reshma Pattan:
> New fields nb_rx_queues and nb_tx_queues will be added to
> rte_eth_dev_info structure.
> Changes to API rte_eth_dev_info_get() will be done to update
> these new fields to rte_eth_dev_info object.
> 
> Signed-off-by:reshma Pattan<reshma.pattan@intel.com>

In general the Signed-off lines are the same as the From: field.
Here it would be:
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
(note the spaces and the uppercase)

> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -90,3 +90,9 @@ Deprecation Notices
>    a handle, like the way kernel exposes an fd to user for locating a
>    specific file, and to keep all major structures internally, so that
>    we are likely to be free from ABI violations in future.
> +
> +* A librte_ether public structure ``rte_eth_dev_info`` will be changed in 16.07.
> +  The proposed change will add new parameters ``nb_rx_queues``, ``nb_tx_queues``
> +  to the structure. These are the number of queues configured by software.
> +  Modification to definition of ``rte_eth_dev_info_get()`` will be done
> +  to update new parameters to ``rte_eth_dev_info`` object.

It is too late for this announce as it won't appear in the doc downloaded for
version 16.04. So it is obviously rejected.
The question here is: are you allowed to do a small ABI change given that
the ABI will be broken in this version?
I would say there can be some exceptional tolerance.
I have no strong opinion myself but maybe others will have one.

By the way, I have some comments about the patch.

[dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct

[Reshma Pattan]

New fields nb_rx_queues and nb_tx_queues are added to
rte_eth_dev_info structure.
Changes to API rte_eth_dev_info_get() are done to update
these new fields to rte_eth_dev_info object.

Signed-off-by:reshma Pattan<reshma.pattan@intel.com>
---
 lib/librte_ether/rte_ethdev.c | 2 ++
 lib/librte_ether/rte_ethdev.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..032c6bf 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1661,6 +1661,8 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
 	(*dev->dev_ops->dev_infos_get)(dev, dev_info);
 	dev_info->pci_dev = dev->pci_dev;
 	dev_info->driver_name = dev->data->drv_name;
+	dev_info->nb_tx_queues = dev->data->nb_tx_queues;
+	dev_info->nb_rx_queues = dev->data->nb_rx_queues;
 }
 
 int
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 022733e..e8e370d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -908,6 +908,9 @@ struct rte_eth_dev_info {
 	struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
 	struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
 	uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_LINK_SPEED_). */
+	/** number of queues configured by software*/
+	uint16_t nb_rx_queues; /**< Number of RX queues. */
+	uint16_t nb_tx_queues; /**< Number of TX queues. */
 };
 
 /**
-- 
2.5.0

Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, April 14, 2016 10:45 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to
> rte_eth_dev_info struct
> 
> New fields nb_rx_queues and nb_tx_queues are added to rte_eth_dev_info
> structure.
> Changes to API rte_eth_dev_info_get() are done to update these new fields
> to rte_eth_dev_info object.
> 
> Signed-off-by:reshma Pattan<reshma.pattan@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct

[Thomas Monjalon]

2016-04-14 10:44, Reshma Pattan:
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -908,6 +908,9 @@ struct rte_eth_dev_info {
>  	struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
>  	struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
>  	uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_LINK_SPEED_). */
> +	/** number of queues configured by software*/
> +	uint16_t nb_rx_queues; /**< Number of RX queues. */
> +	uint16_t nb_tx_queues; /**< Number of TX queues. */
>  };

I think the ethdev design is strange for these structures.
struct rte_eth_dev is internal to be used inside the ethdev API
or by the drivers.
It contains struct rte_eth_dev_data which can be of interest for
the application, except the dev_private part (which could be
directly in struct rte_eth_dev).

So the global question is: how to share the device data with the
application?
Instead of giving a pointer or a copy of struct rte_eth_dev_data,
we have some different accessors:
	- rte_eth_dev_info_get() with a specific struct rte_eth_dev_info
which gathers a lot of info, not only from struct rte_eth_dev_data
	- rte_eth_macaddr_get()
	- rte_eth_dev_socket_id()
	- rte_eth_link_get() which is more than an accessor

I think having some specialized accessors is good.
But the rte_eth_dev_info_get() looks like to be a big request
without precise goal and going to break ABI really often.
There are some queues informations, some (not so precise)
offload capabilities, some steering (RSS/VMDq) informations,
the default configuration of some Intel NIC thresholds,
the speed capabilities, etc.

Shouldn't we try to streamline this API?

Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct

[Ananyev, Konstantin]

Hi everyone,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, April 15, 2016 11:36 AM
> To: Pattan, Reshma
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct
> 
> 2016-04-14 10:44, Reshma Pattan:
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -908,6 +908,9 @@ struct rte_eth_dev_info {
> >  	struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
> >  	struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
> >  	uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_LINK_SPEED_). */
> > +	/** number of queues configured by software*/
> > +	uint16_t nb_rx_queues; /**< Number of RX queues. */
> > +	uint16_t nb_tx_queues; /**< Number of TX queues. */
> >  };
> 
> I think the ethdev design is strange for these structures.
> struct rte_eth_dev is internal to be used inside the ethdev API
> or by the drivers.
> It contains struct rte_eth_dev_data which can be of interest for
> the application, except the dev_private part (which could be
> directly in struct rte_eth_dev).
> 
> So the global question is: how to share the device data with the
> application?
> Instead of giving a pointer or a copy of struct rte_eth_dev_data,
> we have some different accessors:
> 	- rte_eth_dev_info_get() with a specific struct rte_eth_dev_info
> which gathers a lot of info, not only from struct rte_eth_dev_data
> 	- rte_eth_macaddr_get()
> 	- rte_eth_dev_socket_id()
> 	- rte_eth_link_get() which is more than an accessor
> 
> I think having some specialized accessors is good.
> But the rte_eth_dev_info_get() looks like to be a big request
> without precise goal and going to break ABI really often.
> There are some queues informations, some (not so precise)
> offload capabilities, some steering (RSS/VMDq) informations,
> the default configuration of some Intel NIC thresholds,
> the speed capabilities, etc.
> 
> Shouldn't we try to streamline this API?

I think in general it is a good idea  to split dev_info into some smaller sub-pieces.
But introduce a new API just for these 2 fields seems like an overkill to me.
My vote would be to allow nb_rx/tx_queues into dev_info,
If we'll decide to split dev_info - I think it needs to be a subject for a separate   
patch/discussion.
Konstantin