From: Olivier MATZ <olivier.matz@6wind.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: Ivan Boule <ivan.boule@6wind.com>, thomas@monjalon.net, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] ethdev: add administrative information in per-port info
Date: Tue, 12 Dec 2017 12:10:56 +0100 [thread overview]
Message-ID: <20171212111055.wc3cyg2zzcmkmfip@platinum> (raw)
In-Reply-To: <8695b1a0-b717-91d8-8522-9f60fe5d5932@solarflare.com>
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
next prev parent reply other threads:[~2017-12-12 11:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 9:21 Ivan Boule
2017-11-15 9:09 ` Andrew Rybchenko
2017-12-12 11:10 ` Olivier MATZ [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171212111055.wc3cyg2zzcmkmfip@platinum \
--to=olivier.matz@6wind.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ivan.boule@6wind.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).