From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Liang-min" Subject: Re: [PATCH v15 1/4] ethdev: add apis to support access device info Date: Wed, 15 Jul 2015 10:07:15 +0000 Message-ID: References: <1432946276-9424-1-git-send-email-liang-min.wang@intel.com> <1436840331-13112-1-git-send-email-liang-min.wang@intel.com> <1436840331-13112-2-git-send-email-liang-min.wang@intel.com> <7196644.zbOgvuZnbg@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Thomas Monjalon Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A23C7DE6 for ; Wed, 15 Jul 2015 12:07:18 +0200 (CEST) In-Reply-To: <7196644.zbOgvuZnbg@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, July 15, 2015 2:16 AM > To: Wang, Liang-min > Cc: dev@dpdk.org; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v15 1/4] ethdev: add apis to support acces= s > device info >=20 > 2015-07-13 22:18, Liang-Min Larry Wang: > > --- 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 >=20 > This file is not related to ethernet so it could be named rte_dev_info.h >=20 >=20 > > +struct rte_dev_reg_info { > > + void *buf; /**< Buffer for register */ >=20 > Maybe data would be more accurate. >=20 > > + uint32_t offset; /**< Offset for 1st register to fetch */ >=20 > Please precise offset from which point? > Why offset is needed? >=20 Is C always 0-base? The offset is introduced because one of the review requesting to support pa= rtial register read,=20 meaning reading single register or a set of registers. As comment in my reply, this implementation only supports total register du= mp,=20 but the data structure design allows future expansion to support this reque= st. > > + uint32_t leng; /**< Number of registers to fetch */ >=20 > 2 more characters for free: length >=20 >=20 > > +struct rte_dev_eeprom_info { > > + void *buf; /**< Buffer for eeprom */ > > + uint32_t offset; /**< Offset for 1st eeprom location to access */ > > + uint32_t leng; /**< Length of eeprom region to access */ >=20 > Same as above for these 3 fields. >=20 > > + uint32_t magic; /**< Device ID */ >=20 > What means magic? Is it always a device id? This field is the same as defined in kernel ethtool data structure. >=20 >=20 > > --- a/lib/librte_ether/rte_ether_version.map > > +++ b/lib/librte_ether/rte_ether_version.map > > @@ -114,5 +114,11 @@ DPDK_2.1 { > > rte_eth_timesync_enable; > > rte_eth_timesync_read_rx_timestamp; > > rte_eth_timesync_read_tx_timestamp; > > + 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; >=20 > It is not in alphabetical order. Is there a document on such requirement? I'm asking this question because different API's are added at different tim= e. Does this comment apply on relative order or absolute order meaning order r= elative to mainline code?