On Mon, Mar 29, 2021 at 12:19 AM Thomas Monjalon <tho...@monjalon.net> wrote: > > 29/03/2021 09:03, Thomas Monjalon: > > 29/03/2021 06:02, Huisong Li: > > > 'speed_capa' in struct rte_eth_dev_info is defined as follows: > > > > > > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > > > > > > > > > Most PMD drivers use this field to report the speeds capability > > > supported by the device to the upper-layer app. > > > > > > But it seems that few NICs report their auto-negotiation capability > > > through this field. If NIC also uses it to report > > > their auto-negotiation capability through this field, and should set it > > > to ETH_LINK_SPEED_AUTONEG(0) based on > > > the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > > > report of the speeds capability . > > > > > > I don't know how to correctly report the auto-negotiation capability of > > > the device. Thanks for your reply. > > > > ETH_LINK_SPEED_AUTONEG is not for capabilities. > > Anyway, if it is set, it changes nothing (0) in the bitmap. > > I see mlx5 is wrongly using it. > > > > speed_capa is only for enumerating speeds. > > I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa > if the device cannot support autonegotiation. > Should we add a note in doxygen? I think we should do that.
> >
