DPDK patches and discussions
 help / color / mirror / Atom feed
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

  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).