On Mon, Mar 29, 2021 at 12:19 AM Thomas Monjalon [off-list ref] wrote:

29/03/2021 09:03, Thomas Monjalon:

quoted

29/03/2021 06:02, Huisong Li:

quoted

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