[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
Marc Sune
marc.sune at bisdn.de
Wed May 27 11:15:28 CEST 2015
On 27/05/15 06:02, Thomas Monjalon wrote:
> Hi Marc,
>
> 2015-05-26 21:50, Marc Sune:
>> Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.
>>
>> Signed-off-by: Marc Sune <marc.sune at bisdn.de>
> [...]
>> +/**
>> + * Device supported speeds
>> + */
>> +#define ETH_SPEED_CAP_NOT_PHY (0) /*< No phy media > */
> 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.
>
>> +#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.
> 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.
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.
marc
>
More information about the dev
mailing list