[dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info

Ananyev, Konstantin konstantin.ananyev at intel.com
Wed Jun 17 19:25:26 CEST 2015


...
> > > > > > > > > > +
> > > > > > > > > > +int
> > > > > > > > > > +rte_eth_dev_get_ringparam(uint8_t port_id, struct
> > > > > > > > > > +rte_dev_ring_info
> > > > > > > > > > +*info) {
> > > > > > > > > > +	struct rte_eth_dev *dev;
> > > > > > > > > > +
> > > > > > > > > > +	if (!rte_eth_dev_is_valid_port(port_id)) {
> > > > > > > > > > +		PMD_DEBUG_TRACE("Invalid port_id=%d\n",
> > > > > port_id);
> > > > > > > > > > +		return -ENODEV;
> > > > > > > > > > +	}
> > > > > > > > > > +
> > > > > > > > > > +	if ((dev= &rte_eth_devices[port_id]) == NULL) {
> > > > > > > > > > +		PMD_DEBUG_TRACE("Invalid port device\n");
> > > > > > > > > > +		return -ENODEV;
> > > > > > > > > > +	}
> > > > > > > > > > +
> > > > > > > > > > +	FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_ringparam, -
> > > > > > > > > ENOTSUP);
> > > > > > > > > > +	return (*dev->dev_ops->get_ringparam)(dev, info); }
> > > > > > > > >
> > > > > > > > > I think it will be a useful addition to the ethdev API  to
> > > > > > > > > have an ability to retrieve current RX/TX queue parameters.
> > > > > > > > > Though again, it need to be more generic, so it could be
> > > > > > > > > useful for
> > > > > > > > > non- ethtool upper layer too.
> > > > > > > > > So I suggest to modify it a bit.
> > > > > > > > > Something like that:
> > > > > > > > >
> > > > > > > > > struct rte_eth_tx_queue_info {
> > > > > > > > >     struct rte_eth_txconf txconf;
> > > > > > > > >     uint32_t nb_tx_desc;
> > > > > > > > >     uint32_t nb_max_tx_desc; /*max allowable TXDs for that
> > > queue */
> > > > > > > > >     uint32_t nb_tx_free;            /* number of free TXDs at the
> > > moment
> > > > > of
> > > > > > > call.
> > > > > > > > > */
> > > > > > > > >     /* other tx queue data. */ };
> > > > > > > > >
> > > > > > > > > int rte_etdev_get_tx_queue_info(portid, queue_id, struct
> > > > > > > > > rte_eth_tx_queue_info *qinfo)
> > > > > > > > >
> > > > > > > > > Then, your upper layer ethtool wrapper, can implement yours
> > > > > > > > > ethtool_get_ringparam() by:
> > > > > > > > >
> > > > > > > > >  ...
> > > > > > > > >  struct rte_eth_tx_queue_info qinfo;
> > > > > > > > > rte_ethdev_get_tx_queue_info(port, 0, &qinfo);
> > > > > > > > > ring_param->tx_pending = qinfo.nb_tx_desc -
> > > > > > > > > rte_eth_rx_queue_count(port, 0);
> > > > > > > > >
> > > > > > > > > Or probably even:
> > > > > > > > > ring_param->tx_pending = qinfo.nb_tx_desc -
> > > > > > > > > qinfo.nb_tx_free;
> > > > > > > > >
> > > > > > > > > Same for RX.
> > > > > > > > >
> > > > > > > > For now, this descriptor ring information is used by the ethtool op.
> > > > > > > > To make this interface simple, i.e. caller doesn't need to
> > > > > > > > access other
> > > > > > > queue information.
> > > > > > >
> > > > > > > I just repeat what I said to you in off-line conversation:
> > > > > > > ethdev API is not equal ethtool API.
> > > > > > > It is ok to add  a new function/structure to ethdev if it really
> > > > > > > needed, but we should do mechanical one to one copy.
> > > > > > > It is much better to add  a function/structure that would be
> > > > > > > more generic, and suit other users, not only ethtool.
> > > > > > > There is no point to have dozen functions in rte_ethdev API
> > > > > > > providing similar information.
> > > > > > > BTW, I don't see how API I proposed is much more  complex, then
> > > > > > > yours
> > > > > one.
> > > > > > The ring parameter is a run-time information which is different
> > > > > > than data
> > > > > structure described in this discussion.
> > > > >
> > > > > I don't see how they are different.
> > > > > Looking at ixgbe_get_ringparam(), it returns:
> > > > > rx_max_pending - that's a static IXGBE PMD value (max possible
> > > > > number of RXDs per one queue).
> > > > > rx_pending - number of RXD currently in use by the HW for queue 0
> > > > > (that information can be changed at each call).
> > > > >
> > > > > With the approach I suggesting - you can get same information for
> > > > > each RX queue by calling rte_ethdev_get_rx_queue_info() and
> > > > > rte_eth_rx_queue_count().
> > > > > Plus you are getting other RX queue data.
> > > > >
> > > > > Another thing - what is practical usage of the information you
> > > > > retrieving now by get_ringparam()?
> > > > > Let say it returned to you: rx_max_pending=4096; rx_pending=128; How
> > > > > that information would help to understand what is going on with the
> > > device?
> > > > > Without knowing  value of nb_tx_desc for the queue, you can't say is
> > > > > you queue full or not.
> > > > > Again, it could be that all your traffic going through some other
> > > > > queue (not 0).
> > > > > So from my point rte_eth_dev_get_ringparam()  usage is very limited,
> > > > > and doesn't provide enough information about current queue state.
> > > > >
> > > > > Same thing applies for TX.
> > > > >
> > > >
> > > > After careful review the suggestion in this comment, and review the
> > > existing dpdk source code.
> > > > I came to realize that neither rte_ethdev_get_rx_queue_info,
> > > > rte_ethdev_get_tx_queue_info, struct rte_eth_rx_queue_info and struct
> > > > rte_eth_tx_queue_info are available in the existing dpdk source code. I
> > > could not make a patch based upon a set of non- existent API and data
> > > structure.
> > >
> > > Right now, in dpdk.org source code, struct  rte_eth_dev_ring_info, struct
> > > rte_dev_eeprom_info and struct  rte_dev_reg_info don't exist also.
> > > Same as  all these functions:
> > >
> > > rte_eth_dev_default_mac_addr_set
> > > rte_eth_dev_reg_length
> > > rte_eth_dev_reg_info
> > > rte_eth_dev_eeprom_length
> > > rte_eth_dev_get_eeprom
> > > rte_eth_dev_set_eeprom
> > > rte_eth_dev_get_ringparam
> > >
> > > All this is a new API that's you are trying to add.
> > > But, by some reason you consider it is ok to add 'struct
> > > rte_eth_dev_ring_info', but couldn't add  struct
> > > 'rte_ethdev_get_tx_queue_info'
> > > That just doesn't make any sense to me.
> > > In fact, I think our conversation is going in cycles.
> > > If you are not happy with the suggested approach, please provide some
> > > meaningful reason why.
> >
> > All the API's and data structure that you have questions in this comment are available from the submitted patch, you could run to
> see
> > if it works.
> > What I learned from your comments are a couple of API name and incomplete data structure description, so I could not make my
> > patch according to your suggestion.
> > If you strongly feel the API's that you are proposing are useful for get_ringparam(), please create a patch and submit it for
> evaluation.
> 
> Ok, I'll try to create a patch in next few days.
> Hopefully it will make things clearer to you and fit everyone.
> Konstantin

Here is the patch I submitted for proposed changes at re_ethdev and PMDs, as discussed:
http://dpdk.org/dev/patchwork/patch/5482/
Please have a look.

With that, get_ringraram for ethtool shim layer, would look something like:

int
rte_ethtool_get_ringparam(uint8_t port_id,
	struct ethtool_ringparam *ring_param)
{
	struct rte_eth_rx_qinfo rx_qinfo;
                struct rte_eth_tx_qinfo tx_qinfo;
	int status;

                if ((status = rte_eth_rx_queue_info_get (port_id, 0, &rx_qinfo)) != 0)
		return status;

               if ((status = rte_eth_tx_queue_info_get (port_id, 0, &tx_qinfo)) != 0)
		return status;

              memset(ring_param, 0, sizeof(*ring_param)

              ring_param->rx_pending = rx_qinfo.nb_desc;
              ring_param->tx_pending = tx_qinfo.nb_desc;
              ring_param->rx_max_pending = rx_qinfo.max_desc;
              ring_param->tx_max_pending = tx_qinfo.max_desc;

              return 0;
}


As you can see, the changes at ethtool are minimal, while it provides desired info.
>From other side, we have much more generic and easily extendable API at rte_ethdev.

Konstantin

> 
> > As coded in this patch, it's a simple and clean interface and most important, it can be validated and it works.
> >
> > > Konstantin
> > >
> > > >
> > > > > > It's the desire of this patch to separate each data structure to
> > > > > > avoid cross
> > > > > dependency.
> > > > >
> > > > > That's too cryptic to me.
> > > > > Could you explain what cross dependency you are talking about?
> > > > >
> > > > > Konstantin



More information about the dev mailing list