DPDK patches and discussions
 help / color / mirror / Atom feed
From: Marc Sune <marc.sune@bisdn.de>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
Date: Mon, 08 Jun 2015 10:50:28 +0200	[thread overview]
Message-ID: <55755754.4070508@bisdn.de> (raw)
In-Reply-To: <5394923.Bu4Z07Mj4A@xps13>



On 29/05/15 20:23, Thomas Monjalon wrote:
> 2015-05-27 11:15, Marc Sune:
>> On 27/05/15 06:02, Thomas Monjalon wrote:
>>> Why not starting with lower values? Some new drivers may be interested
>>> by lower speed.
>> Ok, but which values? 1Mbps FD/HD? Even lower than that?
>>
>> If you have some NIC(s) in mind with lower values, please point me to
>> that and I will collect&add the missing speeds.
> No sorry, I missed how low your first values were.
>
>>>> +#define ETH_SPEED_CAP_10M_HD	(1 << 0)  /*< 10 Mbps half-duplex> */
>>>> +#define ETH_SPEED_CAP_10M_FD	(1 << 1)  /*< 10 Mbps full-duplex> */
>>>> +#define ETH_SPEED_CAP_100M_HD	(1 << 2)  /*< 100 Mbps half-duplex> */
>>>> +#define ETH_SPEED_CAP_100M_FD	(1 << 3)  /*< 100 Mbps full-duplex> */
>>>> +#define ETH_SPEED_CAP_1G	(1 << 4)  /*< 1 Gbps > */
>>>> +#define ETH_SPEED_CAP_2_5G	(1 << 5)  /*< 2.5 Gbps > */
>>>> +#define ETH_SPEED_CAP_5G	(1 << 6)  /*< 5 Gbps > */
>>>> +#define ETH_SPEED_CAP_10G	(1 << 7)  /*< 10 Mbps > */
>>>> +#define ETH_SPEED_CAP_20G	(1 << 8)  /*< 20 Gbps > */
>>>> +#define ETH_SPEED_CAP_25G	(1 << 9)  /*< 25 Gbps > */
>>>> +#define ETH_SPEED_CAP_40G	(1 << 10)  /*< 40 Gbps > */
>>>> +#define ETH_SPEED_CAP_50G	(1 << 11)  /*< 50 Gbps > */
>>>> +#define ETH_SPEED_CAP_56G	(1 << 12)  /*< 56 Gbps > */
>>>> +#define ETH_SPEED_CAP_100G	(1 << 13)  /*< 100 Gbps > */
>>> We should note that rte_eth_link is using ETH_LINK_SPEED_* constants
>>> which are not some bitmaps so we have to create these new constants.
>> Yes, I can add that to the patch description (1/2).
>>
>>> Furthermore, rte_eth_link.link_speed is an uint16_t so it is limited
>>> to 40G. Should we use some constant bitmaps here also?
>> I also thought about converting link_speed into a bitmap to unify the
>> constants before starting the patch (there is redundancy), but I wanted
>> to be minimally invasive; changing link to a bitmap can break existing apps.
>>
>> I can also merge them if we think is a better idea.
> Maybe. Someone against this idea?

Me. I tried implementing this unified speed constantss, but the problem 
is that for the capabilities full-duplex/half-duplex speeds are unrolled 
(e.g. 100M_HD/100_FD). There is no generic 100M to set a specific speed, 
so if you want a fiex speed and duplex auto-negociation witht the 
current set of constants, it would look weird; e.g. 
link_speed=ETH_SPEED_100M_HD and then set 
link_duplex=ETH_LINK_AUTONEG_DUPLEX):

  232 struct rte_eth_link {
  233         uint16_t link_speed;      /**< ETH_LINK_SPEED_[10, 100, 
1000, 10000] */
  234         uint16_t link_duplex;     /**< ETH_LINK_[HALF_DUPLEX, 
FULL_DUPLEX] */
  235         uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link 
down */
  236 }__attribute__((aligned(8)));     /**< aligned for atomic64 
read/write */

There is another minor point, which is when setting the speed in 
rte_eth_conf:

  840 struct rte_eth_conf {
  841         uint16_t link_speed;
  842         /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */

0 is used for speed auto-negociation, but 0 is also used in the 
capabilities bitmap to indicate no PHY_MEDIA (virtual interface). I 
would have to define something like:

906 #define ETH_SPEED_NOT_PHY   (0)  /*< No phy media > */
907 #define ETH_SPEED_AUTONEG   (0)  /*< Autonegociate speed > */

And use (only) NOT_PHY for a capabilities and _AUTONEG for rte_eth_conf.

The options I see:

a) add to the the list of the current speeds generic 10M/100M/1G speeds 
without HD/FD, and just use these speeds in rte_eth_conf.
b) leave them separated.

I would vote for b), since the a) is not completely clean. 
Opinions&other alternatives welcome.

Marc

>
>>> What about removing _CAP suffix from your constants?
>> I added the suffix to make clearer the distinction with link speeds. I
>> can remove it if we merge both or if we consider it is not necessary.
>>
>>> [...]
>>>> +	uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
>>> If the constants are ETH_SPEED_CAP, why not wording this variable speed_cap?
>> I followed the convention of the existing rx/tx offload capability bitmaps:
>>
>> marc@dev:~/git/bisdn/msune/xdpd/libs/dpdk/lib$ grep _capa\; * -R
>> librte_ether/rte_ethdev.h:    uint32_t rx_offload_capa; /**< Device RX
>> offload capabilities. */
>> librte_ether/rte_ethdev.h:    uint32_t tx_offload_capa; /**< Device TX
>> offload capabilities. */
>>
>> I am fine with speed_cap or speed_caps, but I think we should have some
>> consistency on how we name bitmaps.
> You're right.
>
>> If we would want to make the bitmaps more explicit, we could define some
>> helper typedefs in EAL:
>>
>> typedef uint16_t bitmap16_t;
>> typedef uint32_t bitmap32_t;
>> typedef uint64_t bitmap64_t;
>>
>> and replace the bitmaps of the structs, again specially the ones used by
>> the users.
> No, if we want to show this variable is a bitmap, the variable name
> may be changed, not the type. It would bring clarity when reading code
> using this variable but I think it's not really needed.
>

  reply	other threads:[~2015-06-08  8:50 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 23:45 [dpdk-dev] [RFC PATCH 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-05-11 23:45 ` [dpdk-dev] [RFC PATCH 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info Marc Sune
2015-05-25 17:46   ` Stephen Hemminger
2015-05-26  8:41     ` Marc Sune
2015-05-26 15:03   ` Stephen Hemminger
2015-05-26 15:09     ` Marc Sune
2015-05-11 23:45 ` [dpdk-dev] [RFC PATCH 2/2] Filling speed capability bitmaps in the PMDs Marc Sune
2015-05-25 16:32 ` [dpdk-dev] [RFC PATCH 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-05-26 19:50 ` [dpdk-dev] [PATCH v2 " Marc Sune
2015-05-26 19:50   ` [dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info Marc Sune
2015-05-27  4:02     ` Thomas Monjalon
2015-05-27  9:15       ` Marc Sune
2015-05-29 18:23         ` Thomas Monjalon
2015-06-08  8:50           ` Marc Sune [this message]
2015-06-11  9:08             ` Thomas Monjalon
2015-06-11 14:35               ` Marc Sune
2015-05-26 19:50   ` [dpdk-dev] [PATCH v2 2/2] Filling speed capability bitmaps in the PMDs Marc Sune
2015-05-26 21:20     ` Igor Ryzhov
2015-05-27  8:59       ` Marc Sune
2015-08-28 23:20   ` [dpdk-dev] [PATCH v3 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-08-28 23:20     ` [dpdk-dev] [PATCH v3 1/2] Added ETH_SPEED_ bitmap in rte_eth_dev_info Marc Sune
2015-08-28 23:20     ` [dpdk-dev] [PATCH v3 2/2] Filling speed capability bitmaps in the PMDs Marc Sune
2015-08-29  0:16     ` [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-08-29  0:16       ` [dpdk-dev] [PATCH v4 1/2] Added ETH_SPEED_ bitmap in rte_eth_dev_info Marc Sune
2015-08-29  0:16       ` [dpdk-dev] [PATCH v4 2/2] Filling speed capability bitmaps in the PMDs Marc Sune
2015-09-07 20:52       ` [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-09-08 10:03         ` Nélio Laranjeiro
2015-09-08 20:26           ` Marc Sune
2015-09-09 13:10           ` Nélio Laranjeiro
2015-09-09 13:33             ` Thomas Monjalon
2015-09-13 19:14               ` Marc Sune
2015-09-13 21:18                 ` Thomas Monjalon
2015-09-14 10:02                   ` Nélio Laranjeiro
2015-09-14 10:52                   ` Morten Brørup
2015-09-14 21:33                     ` Marc Sune
2015-09-14 22:50                       ` Morten Brørup
2015-09-15  8:25                         ` Nélio Laranjeiro
2015-09-15  8:48                           ` Marc Sune
2015-09-15  9:39                             ` Morten Brørup
2015-09-15 10:04                             ` Adrien Mazarguil
2015-09-15 10:24                               ` Morten Brørup
2015-09-15 21:20                               ` Marc Sune
2015-09-16 14:41                                 ` Adrien Mazarguil
2015-09-15  7:05                       ` Thomas Monjalon
2015-09-15  7:33                         ` Morten Brørup
2015-09-15  9:06                       ` Morten Brørup
2015-10-04 21:12       ` [dpdk-dev] [PATCH v5 0/4] ethdev: add speed capabilities and refactor link API Marc Sune
2015-10-04 21:12         ` [dpdk-dev] [PATCH v5 1/4] ethdev: Added ETH_SPEED_CAP bitmap for ports Marc Sune
2015-10-04 21:12         ` [dpdk-dev] [PATCH v5 2/4] ethdev: Fill speed capability bitmaps in the PMDs Marc Sune
2015-10-04 21:12         ` [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API Marc Sune
2015-10-05 10:59           ` Neil Horman
2015-10-07 13:31             ` Marc Sune
2015-10-06 13:48           ` Nélio Laranjeiro
2015-10-07 13:37             ` Marc Sune
2016-01-28 17:33           ` Harish Patil
2016-02-02  2:20             ` Stephen Hemminger
2016-02-02 22:30               ` Marc
2016-02-11 15:27                 ` Nélio Laranjeiro
2016-02-11 23:23                   ` Marc
2015-10-04 21:12         ` [dpdk-dev] [PATCH v5 4/4] doc: update with link changes Marc Sune
2015-10-04 21:21         ` [dpdk-dev] [PATCH v5 0/4] ethdev: add speed capabilities and refactor link API Marc Sune
2015-06-18 14:43 [dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info Morten Brørup
2015-06-18 15:06 ` Marc Sune
2015-06-18 15:33   ` Thomas Monjalon

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=55755754.4070508@bisdn.de \
    --to=marc.sune@bisdn.de \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    /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).