[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

[Thomas Monjalon]

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?

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