[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
Marc Sune
marc.sune at bisdn.de
Mon Jun 8 10:50:28 CEST 2015
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 at 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.
>
More information about the dev
mailing list