[dpdk-dev] Questions about reporting auto-negotiation capability

[Huisong Li]

在 2021/3/29 15:19, Thomas Monjalon 写道:
> 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?

Can we use bit 0 to indicate whether the device supports auto-negotiation?

Like,

1/ If device doesn't support auto-negotiation, set bit(0) of the 
'speed_capa' to 1, namely, "speed_capa |= ETH_LINK_SPEED_FIXED".

2/ Other bits of the 'speed_capa' report all the speed capabilities 
supported by the device regardless of the value of bit(0) .

The above behavior is similar to cxgbe, bnxt, and mlx5. In this way, 
users can know whether the device supports auto-negotiation

based on bit(0) and detect the supported speed capabilities based on 
other bits.

After all, this 'speed_capa' and the 'link_speeds' in "rte_eth_conf" 
struct have different purposes.


>
>
> .