2015-06-08 10:50, Marc Sune:
> 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:
> >>>> +#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,
Or we can define ETH_SPEED_CAP_100M and ETH_SPEED_CAP_100M_FD.
Is it possible to have a NIC doing 100M_FD but not 100M_HD?
> 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 > */
Or something like SPEED_UNDEFINED
> 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
