From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 0CA9914E8 for ; Tue, 12 Dec 2017 12:11:09 +0100 (CET) Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1eOiYr-0003tD-A8; Tue, 12 Dec 2017 12:17:25 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 12 Dec 2017 12:10:56 +0100 Date: Tue, 12 Dec 2017 12:10:56 +0100 From: Olivier MATZ To: Andrew Rybchenko Cc: Ivan Boule , thomas@monjalon.net, dev@dpdk.org Message-ID: <20171212111055.wc3cyg2zzcmkmfip@platinum> References: <1504862469-931-1-git-send-email-ivan.boule@6wind.com> <8695b1a0-b717-91d8-8522-9f60fe5d5932@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8695b1a0-b717-91d8-8522-9f60fe5d5932@solarflare.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 11:11:10 -0000 Hi Andrew, On Wed, Nov 15, 2017 at 12:09:24PM +0300, Andrew Rybchenko wrote: > On 09/08/2017 12:21 PM, Ivan Boule wrote: > > To help administrative tasks on DPDK ports, add in the data structure > > rte_eth_dev_info the following per-port information to be supplied > > by the dev_infos_get() function exported by a Poll Mode Driver: > > > > - the set of supported link modes, > > - the set of advertised link modes, > > - the type of port connector, > > - autonegotiation enabled or not. > > Sorry for late response. I've lost it from my view until today's discussion > of > deprecation notice. Sorry also for my late answer, and thank you for your comments. > Just for my understanding. I always considered dev_info as place for > more or less stable information like capabilities and physical restrictions. > Port connector perfectly fits it, but advertised link modes and autoneg > status are more dynamic. May be it is a better way to have dedicated API? > Just would like to raise discussion and understand why finally one or > another way will be chosen. Yes, you are right. I think we can find some exceptions: - nb_rx_queues/nb_tx_queues return the current number of configured queues - the speed capabilities may depend on the SFP, which can be hot-plugged - with a failsafe driver, the capabilities/limits depend on the list of sub-devices - maybe the offload capabilities on a virtio device could depend on the peer configuration. But, yes, a new API is maybe better to avoid adding another exception. Something like rte_eth_media_get() ? > Also see note below about connectors. > > > Set new administrative fields to a default value in rte_eth_dev_info_get() > > before invoking the dev_infos_get() function exported by a PMD, if any. > > > > Once this API change is accepted, the dev_infos_get() function of PMDs > > will be updated accordingly to set these new fields, along with the > > port_infos_display() function of the testpmd to display them. > > > > Signed-off-by: Ivan Boule > > --- > > lib/librte_ether/rte_ethdev.c | 1 + > > lib/librte_ether/rte_ethdev.h | 112 ++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 113 insertions(+) > > > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > > index 0597641..4ca51e1 100644 > > --- a/lib/librte_ether/rte_ethdev.c > > +++ b/lib/librte_ether/rte_ethdev.c > > @@ -1897,6 +1897,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info) > > memset(dev_info, 0, sizeof(struct rte_eth_dev_info)); > > dev_info->rx_desc_lim = lim; > > dev_info->tx_desc_lim = lim; > > + dev_info->connector = RTE_ETH_CONNECTOR_OTHER; > > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); > > (*dev->dev_ops->dev_infos_get)(dev, dev_info); > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > > index 0adf327..ac49380 100644 > > --- a/lib/librte_ether/rte_ethdev.h > > +++ b/lib/librte_ether/rte_ethdev.h > > @@ -935,6 +935,113 @@ struct rte_pci_device; > > /** > > * Ethernet device information > > */ > > + > > +/* Types of port connector. */ > > +#define RTE_ETH_CONNECTOR_TP 0x00 /**< Twisted Pair */ > > +#define RTE_ETH_CONNECTOR_AUI 0x01 /**< Attachment Unit Interface */ > > +#define RTE_ETH_CONNECTOR_MII 0x02 /**< Media-Independent Interface */ > > +#define RTE_ETH_CONNECTOR_FIBRE 0x03 /**< Fiber */ > > +#define RTE_ETH_CONNECTOR_DA 0x05 /**< Direct Attach */ > > I thought that examples of connectors are rather RG45, SFP, SFP+, QSFP+, > SFP28, QSFP28. > Media could be twisted pair, fibre, direct attach etc. The types of connectors are derivated from Linux ethtool. But thinking at it, directly copying the defines would cause licensing issues since ethtool is GPL. Unfortunatly, I don't know that much about the different types of connectors and media. I found some inputs on the wikipedia page ( https://en.wikipedia.org/wiki/Ethernet_physical_layer ), but any additional input is welcome :) > > +#define RTE_ETH_CONNECTOR_NONE 0xef > > +#define RTE_ETH_CONNECTOR_OTHER 0xff > > + > > +/* Link modes. */ > > +#define RTE_ETH_LINK_MODE_10baseT_Half_BIT 0 > > +#define RTE_ETH_LINK_MODE_10baseT_Full_BIT 1 > > +#define RTE_ETH_LINK_MODE_100baseT_Half_BIT 2 > > +#define RTE_ETH_LINK_MODE_100baseT_Full_BIT 3 > > +#define RTE_ETH_LINK_MODE_1000baseT_Half_BIT 4 > > +#define RTE_ETH_LINK_MODE_1000baseT_Full_BIT 5 > > +#define RTE_ETH_LINK_MODE_Autoneg_BIT 6 > > +#define RTE_ETH_LINK_MODE_TP_BIT 7 > > +#define RTE_ETH_LINK_MODE_AUI_BIT 8 > > +#define RTE_ETH_LINK_MODE_MII_BIT 9 > > +#define RTE_ETH_LINK_MODE_FIBRE_BIT 10 > > +#define RTE_ETH_LINK_MODE_BNC_BIT 11 > > +#define RTE_ETH_LINK_MODE_10000baseT_Full_BIT 12 > > +#define RTE_ETH_LINK_MODE_Pause_BIT 13 > > +#define RTE_ETH_LINK_MODE_Asym_Pause_BIT 14 > > +#define RTE_ETH_LINK_MODE_2500baseX_Full_BIT 15 > > +#define RTE_ETH_LINK_MODE_Backplane_BIT 16 > > +#define RTE_ETH_LINK_MODE_1000baseKX_Full_BIT 17 > > +#define RTE_ETH_LINK_MODE_10000baseKX4_Full_BIT 18 > > +#define RTE_ETH_LINK_MODE_10000baseKR_Full_BIT 19 > > +#define RTE_ETH_LINK_MODE_10000baseR_FEC_BIT 20 > > +#define RTE_ETH_LINK_MODE_20000baseMLD2_Full_BIT 21 > > +#define RTE_ETH_LINK_MODE_20000baseKR2_Full_BIT 22 > > +#define RTE_ETH_LINK_MODE_40000baseKR4_Full_BIT 23 > > +#define RTE_ETH_LINK_MODE_40000baseCR4_Full_BIT 24 > > +#define RTE_ETH_LINK_MODE_40000baseSR4_Full_BIT 25 > > +#define RTE_ETH_LINK_MODE_40000baseLR4_Full_BIT 26 > > +#define RTE_ETH_LINK_MODE_56000baseKR4_Full_BIT 27 > > +#define RTE_ETH_LINK_MODE_56000baseCR4_Full_BIT 28 > > +#define RTE_ETH_LINK_MODE_56000baseSR4_Full_BIT 29 > > +#define RTE_ETH_LINK_MODE_56000baseLR4_Full_BIT 30 > > +#define RTE_ETH_LINK_MODE_25000baseCR_Full_BIT 31 > > +#define RTE_ETH_LINK_MODE_25000baseKR_Full_BIT 32 > > +#define RTE_ETH_LINK_MODE_25000baseSR_Full_BIT 33 > > +#define RTE_ETH_LINK_MODE_50000baseCR2_Full_BIT 34 > > +#define RTE_ETH_LINK_MODE_50000baseKR2_Full_BIT 35 > > +#define RTE_ETH_LINK_MODE_100000baseKR4_Full_BIT 36 > > +#define RTE_ETH_LINK_MODE_100000baseSR4_Full_BIT 37 > > +#define RTE_ETH_LINK_MODE_100000baseCR4_Full_BIT 38 > > +#define RTE_ETH_LINK_MODE_100000baseLR4_ER4_Full_BIT 39 > > +#define RTE_ETH_LINK_MODE_50000baseSR2_Full_BIT 40 > > +#define RTE_ETH_LINK_MODE_1000baseX_Full_BIT 41 > > +#define RTE_ETH_LINK_MODE_10000baseCR_Full_BIT 42 > > +#define RTE_ETH_LINK_MODE_10000baseSR_Full_BIT 43 > > +#define RTE_ETH_LINK_MODE_10000baseLR_Full_BIT 44 > > +#define RTE_ETH_LINK_MODE_10000baseLRM_Full_BIT 45 > > +#define RTE_ETH_LINK_MODE_10000baseER_Full_BIT 46 > > +#define RTE_ETH_LINK_MODE_2500baseT_Full_BIT 47 > > +#define RTE_ETH_LINK_MODE_5000baseT_Full_BIT 48 > > + > > +#define RTE_ETH_LINK_MODE_BIT(link_mode_base_name) \ > > + (RTE_ETH_LINK_MODE_ ## link_mode_base_name ## _BIT) So, same here, these link modes are from ethtool and should not be used. We could try to build our own from FreeBSD's media type: http://fxr.watson.org/fxr/source/net/if_media.h#L393 Thoughts? Olivier