From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7CAD12716 for ; Mon, 15 Jun 2015 15:46:18 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 15 Jun 2015 06:46:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,618,1427785200"; d="scan'208";a="588089742" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 15 Jun 2015 06:46:13 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.73]) by IRSMSX102.ger.corp.intel.com ([169.254.2.36]) with mapi id 14.03.0224.002; Mon, 15 Jun 2015 14:45:42 +0100 From: "Ananyev, Konstantin" To: "Wang, Liang-min" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info Thread-Index: AQHQo4/Uz84r4LZBA0eIhB09B1a4pJ2nKH/wgAAL/ACAABF3kIAAg7QAgAD8UZCABL/bgIAAEg9w Date: Mon, 15 Jun 2015 13:45:42 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836A0A7FF@irsmsx105.ger.corp.intel.com> References: <1432946276-9424-1-git-send-email-liang-min.wang@intel.com> <1433948996-9716-1-git-send-email-liang-min.wang@intel.com> <1433948996-9716-2-git-send-email-liang-min.wang@intel.com> <2601191342CEEE43887BDE71AB97725836A08BA3@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836A08BD4@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836A08FD3@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 13:46:20 -0000 > -----Original Message----- > From: Wang, Liang-min > Sent: Monday, June 15, 2015 2:26 PM > To: Ananyev, Konstantin; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access= device info >=20 >=20 >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Friday, June 12, 2015 8:31 AM > > To: Wang, Liang-min; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support acce= ss > > device info > > > > > > > > > -----Original Message----- > > > From: Wang, Liang-min > > > Sent: Thursday, June 11, 2015 10:51 PM > > > To: Ananyev, Konstantin; dev@dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support > > > access device info > > > > > > > > > > > > > -----Original Message----- > > > > From: Ananyev, Konstantin > > > > Sent: Thursday, June 11, 2015 9:07 AM > > > > To: Wang, Liang-min; dev@dpdk.org > > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support > > > > access device info > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Wang, Liang-min > > > > > Sent: Thursday, June 11, 2015 1:58 PM > > > > > To: Ananyev, Konstantin; dev@dpdk.org > > > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to suppor= t > > > > > access device info > > > > > > > > > > Hi Konstantin, > > > > > > > > > > > -----Original Message----- > > > > > > From: Ananyev, Konstantin > > > > > > Sent: Thursday, June 11, 2015 8:26 AM > > > > > > To: Wang, Liang-min; dev@dpdk.org > > > > > > Cc: Wang, Liang-min > > > > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to > > > > > > support access device info > > > > > > > > > > > > Hi Larry, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Liang-Mi= n > > > > > > > Larry Wang > > > > > > > Sent: Wednesday, June 10, 2015 4:10 PM > > > > > > > To: dev@dpdk.org > > > > > > > Cc: Wang, Liang-min > > > > > > > Subject: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to suppor= t > > > > > > > access device info > > > > > > > > > > > > > > add new apis: > > > > > > > - rte_eth_dev_default_mac_addr_set > > > > > > > - rte_eth_dev_reg_leng > > > > > > > - rte_eth_dev_reg_info > > > > > > > - rte_eth_dev_eeprom_leng > > > > > > > - rte_eth_dev_get_eeprom > > > > > > > - rte_eth_dev_set_eeprom > > > > > > > - rte_eth_dev_get_ringparam > > > > > > > - rte_eth_dev_set_ringparam > > > > > > > > > > > > > > to enable reading device parameters (mac-addr, register, > > > > > > > eeprom, > > > > > > > ring) based upon ethtool alike data parameter specification. > > > > > > > > > > > > > > Signed-off-by: Liang-Min Larry Wang > > > > > > > --- > > > > > > > lib/librte_ether/Makefile | 1 + > > > > > > > lib/librte_ether/rte_eth_dev_info.h | 80 +++++++++++++++= ++ > > > > > > > lib/librte_ether/rte_ethdev.c | 159 > > > > > > +++++++++++++++++++++++++++++++++ > > > > > > > lib/librte_ether/rte_ethdev.h | 158 > > > > > > ++++++++++++++++++++++++++++++++ > > > > > > > lib/librte_ether/rte_ether_version.map | 8 ++ > > > > > > > 5 files changed, 406 insertions(+) create mode 100644 > > > > > > > lib/librte_ether/rte_eth_dev_info.h > > > > > > > > > > > > > > diff --git a/lib/librte_ether/Makefile > > > > > > > b/lib/librte_ether/Makefile index c0e5768..05209e9 100644 > > > > > > > --- a/lib/librte_ether/Makefile > > > > > > > +++ b/lib/librte_ether/Makefile > > > > > > > @@ -51,6 +51,7 @@ SRCS-y +=3D rte_ethdev.c SYMLINK-y-include= +=3D > > > > > > > rte_ether.h SYMLINK-y-include +=3D rte_ethdev.h > > > > > > > SYMLINK-y-include > > > > > > > +=3D rte_eth_ctrl.h > > > > > > > +SYMLINK-y-include +=3D rte_eth_dev_info.h > > > > > > > > > > > > > > # this lib depends upon: > > > > > > > DEPDIRS-y +=3D lib/librte_eal lib/librte_mempool > > > > > > > lib/librte_ring lib/librte_mbuf diff --git > > > > > > > a/lib/librte_ether/rte_eth_dev_info.h > > > > > > > b/lib/librte_ether/rte_eth_dev_info.h > > > > > > > new file mode 100644 > > > > > > > index 0000000..002c4b5 > > > > > > > --- /dev/null > > > > > > > +++ b/lib/librte_ether/rte_eth_dev_info.h > > > > > > > @@ -0,0 +1,80 @@ > > > > > > > +/*- > > > > > > > + * BSD LICENSE > > > > > > > + * > > > > > > > + * Copyright(c) 2015 Intel Corporation. All rights reserve= d. > > > > > > > + * All rights reserved. > > > > > > > + * > > > > > > > + * Redistribution and use in source and binary forms, with= or > > without > > > > > > > + * modification, are permitted provided that the following > > conditions > > > > > > > + * are met: > > > > > > > + * > > > > > > > + * * Redistributions of source code must retain the abov= e > > copyright > > > > > > > + * notice, this list of conditions and the following d= isclaimer. > > > > > > > + * * Redistributions in binary form must reproduce the a= bove > > > > copyright > > > > > > > + * notice, this list of conditions and the following d= isclaimer in > > > > > > > + * the documentation and/or other materials provided w= ith the > > > > > > > + * distribution. > > > > > > > + * * Neither the name of Intel Corporation nor the names= of its > > > > > > > + * contributors may be used to endorse or promote prod= ucts > > > > derived > > > > > > > + * from this software without specific prior written p= ermission. > > > > > > > + * > > > > > > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > > > > > > CONTRIBUTORS > > > > > > > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, > > INCLUDING, > > > > BUT > > > > > > NOT > > > > > > > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY > > AND > > > > > > FITNESS FOR > > > > > > > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL > > THE > > > > > > COPYRIGHT > > > > > > > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, > > INDIRECT, > > > > > > INCIDENTAL, > > > > > > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > > > > (INCLUDING, > > > > > > BUT NOT > > > > > > > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > > SERVICES; > > > > > > LOSS OF USE, > > > > > > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER > > > > CAUSED > > > > > > AND ON ANY > > > > > > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > > LIABILITY, > > > > OR > > > > > > TORT > > > > > > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > > WAY > > > > OUT > > > > > > OF THE USE > > > > > > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > > SUCH > > > > > > DAMAGE. > > > > > > > + */ > > > > > > > + > > > > > > > +#ifndef _RTE_ETH_DEV_INFO_H_ > > > > > > > +#define _RTE_ETH_DEV_INFO_H_ > > > > > > > + > > > > > > > + > > > > > > > +/* > > > > > > > + * Placeholder for accessing device registers */ struct > > > > > > > +rte_dev_reg_info { > > > > > > > + void *buf; /**< Buffer for register */ > > > > > > > + uint32_t offset; /**< Offset for 1st register to fetch */ > > > > > > > + uint32_t leng; /**< Number of registers to fetch */ > > > > > > > + uint32_t version; /**< Device version */ }; > > > > > > > + > > > > > > > +/* > > > > > > > + * Placeholder for accessing device eeprom */ struct > > > > > > > +rte_dev_eeprom_info { > > > > > > > + void *buf; /**< Buffer for eeprom */ > > > > > > > + uint32_t offset; /**< Offset for 1st eeprom location to acc= ess > > */ > > > > > > > + uint32_t leng; /**< Length of eeprom region to access */ > > > > > > > + uint32_t magic; /**< Device ID */ }; > > > > > > > + > > > > > > > +/* > > > > > > > + * Placeholder for accessing device ring parameters */ > > > > > > > +struct rte_dev_ring_info { > > > > > > > + uint32_t rx_pending; /**< Number of outstanding Rx ring */ > > > > > > > + uint32_t tx_pending; /**< Number of outstanding Tx ring */ > > > > > > > + uint32_t rx_max_pending; /**< Maximum number of > > outstanding > > > > > > > +Rx > > > > > > ring */ > > > > > > > + uint32_t tx_max_pending; /**< Maximum number of > > outstanding > > > > > > > +Tx > > > > > > ring > > > > > > > +*/ }; > > > > > > > + > > > > > > > +/* > > > > > > > + * A data structure captures information as defined in struc= t > > > > > > > +ifla_vf_info > > > > > > > + * for user-space api > > > > > > > + */ > > > > > > > +struct rte_dev_vf_info { > > > > > > > + uint32_t vf; > > > > > > > + uint8_t mac[ETHER_ADDR_LEN]; > > > > > > > + uint32_t vlan; > > > > > > > + uint32_t tx_rate; > > > > > > > + uint32_t spoofchk; > > > > > > > +}; > > > > > > > > > > > > > > > > > > Wonder what that structure is for? > > > > > > I can't see it used in any function below? > > > > > > > > > > > > > > > > Good catch, this is designed for other ethtool ops that I did not > > > > > include in > > > > this release, I will remove this from next fix. > > > > > > > > > > > > + > > > > > > > +#endif /* _RTE_ETH_DEV_INFO_H_ */ > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > > > > > b/lib/librte_ether/rte_ethdev.c index 5a94654..186e85c 100644 > > > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > > > @@ -2751,6 +2751,32 @@ rte_eth_dev_mac_addr_remove(uint8_t > > > > > > port_id, > > > > > > > struct ether_addr *addr) } > > > > > > > > > > > > > > int > > > > > > > +rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct > > > > > > > +ether_addr > > > > > > > +*addr) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + const int index =3D 0; > > > > > > > + const uint32_t pool =3D 0; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + dev =3D &rte_eth_devices[port_id]; > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops- > > >mac_addr_remove, - > > > > > > ENOTSUP); > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_add, - > > > > > > ENOTSUP); > > > > > > > + > > > > > > > + /* Update NIC default MAC address*/ > > > > > > > + (*dev->dev_ops->mac_addr_remove)(dev, index); > > > > > > > + (*dev->dev_ops->mac_addr_add)(dev, addr, index, pool); > > > > > > > + > > > > > > > + /* Update default address in NIC data structure */ > > > > > > > + ether_addr_copy(addr, &dev->data->mac_addrs[index]); > > > > > > > + > > > > > > > + return 0; > > > > > > > +} > > > > > > > + > > > > > > > +int > > > > > > > rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf, > > > > > > > uint16_t rx_mode, uint8_t on) { @@ > > -3627,3 > > > > +3653,136 @@ > > > > > > > rte_eth_remove_tx_callback(uint8_t port_id, > > > > > > uint16_t queue_id, > > > > > > > /* Callback wasn't found. */ > > > > > > > return -EINVAL; > > > > > > > } > > > > > > > + > > > > > > > +int > > > > > > > +rte_eth_dev_reg_leng(uint8_t port_id) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg_length, > > - > > > > > > ENOTSUP); > > > > > > > + return (*dev->dev_ops->get_reg_length)(dev); > > > > > > > +} > > > > > > > + > > > > > > > +int > > > > > > > +rte_eth_dev_reg_info(uint8_t port_id, struct rte_dev_reg_inf= o > > > > > > > +*info) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg, - > > ENOTSUP); > > > > > > > + return (*dev->dev_ops->get_reg)(dev, info); } > > > > > > > > > > > > Seems that *get_reg* stuff, will be really good addition for > > > > > > DPDK debugging abilities. > > > > > > Though, I'd suggest we change it a bit to make more generic and > > flexible: > > > > > > > > > > > > Introduce rte_eth_reg_read/rte_eth_reg_write(), > > > > > > or probably even better rte_pcidev_reg_read > > > > > > /rte_pcidev_reg_write at > > > > EAL. > > > > > > Something similar to what port_pci_reg_read/port_pci_reg_write(= ) > > > > > > are doing now at testpmd.h. > > > > > > > > > > > > struct rte_pcidev_reg_info { > > > > > > const char *name; > > > > > > uint32_t endianes, bar, offset, size, count; }; > > > > > > > > > > > > int rte_pcidev_reg_read(const struct rte_pci_device *, const > > > > > > struct rte_pcidev_reg_info *, uint64_t *reg_val); > > > > > > > > > > > > Then: > > > > > > int rte_eth_dev_get_reg_info(port_id, const struct > > > > > > rte_pcidev_reg_info **info); > > > > > > > > > > > > So each device would store in info a pointer to an array of it'= s > > > > > > register descriptions (finished by zero elem?). > > > > > > > > > > > > Then your ethtool (or any other upper layer) can do the > > > > > > following to read all device regs: > > > > > > > > > > > > > > > > The proposed reg info structure allows future improvement to > > > > > support > > > > individual register read/write. > > > > > Also, because each NIC device has a very distinguish register def= inition. > > > > > So, the plan is to have more comprehensive interface to support > > > > > query operation (for example, register name) before introduce > > > > > individual/group > > > > register access. > > > > > Points taken, the support will be in future release. > > > > > > > > Sorry, didn't get you. > > > > So you are ok to make these changes in next patch version? > > > > > > > I would like to get a consensus from dpdk community on how to provide > > register information. > > > > Well, that' ok, but if it is just a trial patch that is not intended to= be applied, > > then you should mark it as RFC. > > > > > Currently, it's designed for debug dumping. The register information = is very > > hardware dependent. > > > Need to consider current supported NIC device and future devices for > > DPDK, so we won't make it a bulky interface. > > > > Ok, could you explain what exactly concerns you in the approach descri= bed > > above? > > What part you feel is bulky? > > > > > > > > > > > > > const struct rte_eth_dev_reg_info *reg_info; struct > > > > > > rte_eth_dev_info dev_info; > > > > > > > > > > > > rte_eth_dev_info_get(pid, &dev_info); > > > > > > rte_eth_dev_get_reg_info(port_id, ®_info); > > > > > > > > > > > > for (i =3D 0; reg_info[i].name !=3D NULL; i++) { > > > > > > ... > > > > > > rte_pcidev_read_reg(dev_info. pci_dev, reg_info[i], &v); > > > > > > .. > > > > > > } > > > > > > > > > > > > > + > > > > > > > +int > > > > > > > +rte_eth_dev_eeprom_leng(uint8_t port_id) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops- > > >get_eeprom_length, - > > > > > > ENOTSUP); > > > > > > > + return (*dev->dev_ops->get_eeprom_length)(dev); > > > > > > > +} > > > > > > > + > > > > > > > +int > > > > > > > +rte_eth_dev_get_eeprom(uint8_t port_id, struct > > > > > > > +rte_dev_eeprom_info > > > > > > > +*info) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_eeprom, - > > > > > > ENOTSUP); > > > > > > > + return (*dev->dev_ops->get_eeprom)(dev, info); } > > > > > > > + > > > > > > > +int > > > > > > > +rte_eth_dev_set_eeprom(uint8_t port_id, struct > > > > > > > +rte_dev_eeprom_info > > > > > > > +*info) { > > > > > > > + struct rte_eth_dev *dev; > > > > > > > + > > > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, - > > > > > > ENOTSUP); > > > > > > > + return (*dev->dev_ops->set_eeprom)(dev, info); } > > > > > > > + > > > > > > > +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=3D%d\n", > > port_id); > > > > > > > + return -ENODEV; > > > > > > > + } > > > > > > > + > > > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D 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 queu= e */ > > > > > > uint32_t nb_tx_free; /* number of free TXDs at t= he 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 =3D qinfo.nb_tx_desc - > > > > > > rte_eth_rx_queue_count(port, 0); > > > > > > > > > > > > Or probably even: > > > > > > ring_param->tx_pending =3D 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 you= rs > > 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 o= f > > 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 retrievi= ng now > > by get_ringparam()? > > Let say it returned to you: rx_max_pending=3D4096; rx_pending=3D128; Ho= w 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 yo= u > > 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, an= d > > doesn't provide enough information about current queue state. > > > > Same thing applies for TX. > > >=20 > After careful review the suggestion in this comment, and review the exist= ing dpdk source code. > I came to realize that neither rte_ethdev_get_rx_queue_info, rte_ethdev_g= et_tx_queue_info, struct rte_eth_rx_queue_info and > struct rte_eth_tx_queue_info are available in the existing dpdk source co= de. 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 meani= ngful reason why. Konstantin >=20 > > > It's the desire of this patch to separate each data structure to avoi= d cross > > dependency. > > > > That's too cryptic to me. > > Could you explain what cross dependency you are talking about? > > > > Konstantin