* [dpdk-dev] [RFC] ethdev: add administrative information in per-port info @ 2017-09-08 9:21 Ivan Boule 2017-11-15 9:09 ` Andrew Rybchenko 0 siblings, 1 reply; 7+ messages in thread From: Ivan Boule @ 2017-09-08 9:21 UTC (permalink / raw) To: thomas; +Cc: dev 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. 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 <ivan.boule@6wind.com> --- 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 */ +#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) + +/** + * Provide a set of inline functions to make PMDs and DPDK applications + * independent of the actual layout of the bitmaps used to represent + * the set of supported link modes and the set of advertised link modes. + * Hence, if more then 64 bits (say 70 bits for instance) are needed for + * new link modes: + * 1) the "rte_eth_link_modes" data structure can be modified as follows: + * struct rte_eth_link_modes { + * uint16_t bitmap[5]; + * }; + * 2) the rte_eth_link_mode_ functions below can be adapted to compute from + * the link mode bit the corresponding index of the 16-bit entry in the + * bitmap array and, within it, the appropriate bit to set/reset/get/test. + */ +struct rte_eth_link_modes { + uint64_t bitmap64; /**< Link modes bitmap (RTE_ETH_LINK_MODE_) */ +}; + +static inline void +rte_eth_link_mode_zero(struct rte_eth_link_modes *lk_modes) +{ + lk_modes->bitmap64 = 0; +} + +static inline void +rte_eth_link_mode_set(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) +{ + lk_modes->bitmap64 |= (1ULL << lk_mode_bit); +} + +static inline void +rte_eth_link_mode_reset(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) +{ + lk_modes->bitmap64 &= ~(1ULL << lk_mode_bit); +} + +static inline int +rte_eth_link_mode_is_set(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) +{ + return ((uint64_t)(lk_modes->bitmap64 & (1ULL << lk_mode_bit)) == + (uint64_t) (1ULL << lk_mode_bit)); +} + struct rte_eth_dev_info { struct rte_pci_device *pci_dev; /**< Device PCI information. */ const char *driver_name; /**< Device Driver name. */ @@ -967,6 +1074,11 @@ struct rte_eth_dev_info { /** Configured number of rx/tx queues */ uint16_t nb_rx_queues; /**< Number of RX queues. */ uint16_t nb_tx_queues; /**< Number of TX queues. */ + /** Information useful for administrative purposes. */ + struct rte_eth_link_modes supported_modes; /**< Supported link modes */ + struct rte_eth_link_modes advertised_modes; /**< Advertised " */ + uint8_t connector; /**< RTE_ETH_CONNECTOR_ */ + uint8_t autoneg_enabled : 1; /**< autonegotiation enabled (1) or not */ }; /** -- 2.1.4 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2017-09-08 9:21 [dpdk-dev] [RFC] ethdev: add administrative information in per-port info Ivan Boule @ 2017-11-15 9:09 ` Andrew Rybchenko 2017-12-12 11:10 ` Olivier MATZ 0 siblings, 1 reply; 7+ messages in thread From: Andrew Rybchenko @ 2017-11-15 9:09 UTC (permalink / raw) To: Ivan Boule, thomas; +Cc: dev 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. 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. 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 <ivan.boule@6wind.com> > --- > 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. > +#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) > + > +/** > + * Provide a set of inline functions to make PMDs and DPDK applications > + * independent of the actual layout of the bitmaps used to represent > + * the set of supported link modes and the set of advertised link modes. > + * Hence, if more then 64 bits (say 70 bits for instance) are needed for > + * new link modes: > + * 1) the "rte_eth_link_modes" data structure can be modified as follows: > + * struct rte_eth_link_modes { > + * uint16_t bitmap[5]; > + * }; > + * 2) the rte_eth_link_mode_ functions below can be adapted to compute from > + * the link mode bit the corresponding index of the 16-bit entry in the > + * bitmap array and, within it, the appropriate bit to set/reset/get/test. > + */ > +struct rte_eth_link_modes { > + uint64_t bitmap64; /**< Link modes bitmap (RTE_ETH_LINK_MODE_) */ > +}; > + > +static inline void > +rte_eth_link_mode_zero(struct rte_eth_link_modes *lk_modes) > +{ > + lk_modes->bitmap64 = 0; > +} > + > +static inline void > +rte_eth_link_mode_set(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) > +{ > + lk_modes->bitmap64 |= (1ULL << lk_mode_bit); > +} > + > +static inline void > +rte_eth_link_mode_reset(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) > +{ > + lk_modes->bitmap64 &= ~(1ULL << lk_mode_bit); > +} > + > +static inline int > +rte_eth_link_mode_is_set(struct rte_eth_link_modes *lk_modes, int lk_mode_bit) > +{ > + return ((uint64_t)(lk_modes->bitmap64 & (1ULL << lk_mode_bit)) == > + (uint64_t) (1ULL << lk_mode_bit)); > +} > + > struct rte_eth_dev_info { > struct rte_pci_device *pci_dev; /**< Device PCI information. */ > const char *driver_name; /**< Device Driver name. */ > @@ -967,6 +1074,11 @@ struct rte_eth_dev_info { > /** Configured number of rx/tx queues */ > uint16_t nb_rx_queues; /**< Number of RX queues. */ > uint16_t nb_tx_queues; /**< Number of TX queues. */ > + /** Information useful for administrative purposes. */ > + struct rte_eth_link_modes supported_modes; /**< Supported link modes */ > + struct rte_eth_link_modes advertised_modes; /**< Advertised " */ > + uint8_t connector; /**< RTE_ETH_CONNECTOR_ */ > + uint8_t autoneg_enabled : 1; /**< autonegotiation enabled (1) or not */ > }; > > /** ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2017-11-15 9:09 ` Andrew Rybchenko @ 2017-12-12 11:10 ` Olivier MATZ 2019-03-26 15:09 ` Ferruh Yigit 0 siblings, 1 reply; 7+ messages in thread From: Olivier MATZ @ 2017-12-12 11:10 UTC (permalink / raw) To: Andrew Rybchenko; +Cc: Ivan Boule, thomas, dev 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 <ivan.boule@6wind.com> > > --- > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2017-12-12 11:10 ` Olivier MATZ @ 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:35 ` Ferruh Yigit 0 siblings, 2 replies; 7+ messages in thread From: Ferruh Yigit @ 2019-03-26 15:09 UTC (permalink / raw) To: Olivier MATZ, ivan.boule, Andrew Rybchenko; +Cc: Thomas Monjalon, dpdk-dev On 12/12/2017 11:10 AM, olivier.matz at 6wind.com (Olivier MATZ) wrote: > 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 <ivan.boule at 6wind.com> >>> --- >>> 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? Hi Olivier, The patch is waiting for comments since end of 2017, any objection to reject it? If this is still relevant would you mind sending a up to date version of it? Thanks, ferruh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2019-03-26 15:09 ` Ferruh Yigit @ 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:35 ` Ferruh Yigit 1 sibling, 0 replies; 7+ messages in thread From: Ferruh Yigit @ 2019-03-26 15:09 UTC (permalink / raw) To: Olivier MATZ, ivan.boule, Andrew Rybchenko; +Cc: Thomas Monjalon, dpdk-dev On 12/12/2017 11:10 AM, olivier.matz at 6wind.com (Olivier MATZ) wrote: > 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 <ivan.boule at 6wind.com> >>> --- >>> 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? Hi Olivier, The patch is waiting for comments since end of 2017, any objection to reject it? If this is still relevant would you mind sending a up to date version of it? Thanks, ferruh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:09 ` Ferruh Yigit @ 2019-03-26 15:35 ` Ferruh Yigit 2019-03-26 15:35 ` Ferruh Yigit 1 sibling, 1 reply; 7+ messages in thread From: Ferruh Yigit @ 2019-03-26 15:35 UTC (permalink / raw) To: Olivier MATZ, ivan.boule, Andrew Rybchenko; +Cc: Thomas Monjalon, dpdk-dev On 3/26/2019 3:09 PM, Ferruh Yigit wrote: > On 12/12/2017 11:10 AM, olivier.matz at 6wind.com (Olivier MATZ) wrote: >> 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 <ivan.boule at 6wind.com> >>>> --- >>>> 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? > > Hi Olivier, > > The patch is waiting for comments since end of 2017, any objection to reject it? > If this is still relevant would you mind sending a up to date version of it? For reference, pathwork ids: https://patches.dpdk.org/patch/28508/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info 2019-03-26 15:35 ` Ferruh Yigit @ 2019-03-26 15:35 ` Ferruh Yigit 0 siblings, 0 replies; 7+ messages in thread From: Ferruh Yigit @ 2019-03-26 15:35 UTC (permalink / raw) To: Olivier MATZ, ivan.boule, Andrew Rybchenko; +Cc: Thomas Monjalon, dpdk-dev On 3/26/2019 3:09 PM, Ferruh Yigit wrote: > On 12/12/2017 11:10 AM, olivier.matz at 6wind.com (Olivier MATZ) wrote: >> 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 <ivan.boule at 6wind.com> >>>> --- >>>> 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? > > Hi Olivier, > > The patch is waiting for comments since end of 2017, any objection to reject it? > If this is still relevant would you mind sending a up to date version of it? For reference, pathwork ids: https://patches.dpdk.org/patch/28508/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-26 15:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-08 9:21 [dpdk-dev] [RFC] ethdev: add administrative information in per-port info Ivan Boule 2017-11-15 9:09 ` Andrew Rybchenko 2017-12-12 11:10 ` Olivier MATZ 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:09 ` Ferruh Yigit 2019-03-26 15:35 ` Ferruh Yigit 2019-03-26 15:35 ` Ferruh Yigit
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).