[dpdk-dev] [PATCH] net/bonding: fix link properties with autoneg
Ferruh Yigit
ferruh.yigit at intel.com
Thu Jun 14 19:04:54 CEST 2018
On 4/16/2018 8:09 PM, Matan Azrad wrote:
> Hi Chas
>
> From: Chas Williams, Monday, April 16, 2018 7:44 PM
>> On Mon, Apr 16, 2018 at 4:06 AM, Matan Azrad <matan at mellanox.com>
>> wrote:
>>> Hi Chas
>>>
>>> From: Chas Williams, Wednesday, February 14, 2018 12:55 AM
>>>> If a link is carrier down and using autonegotiation, then the PMD may
>>>> not have detected a speed yet. In this case the best we can do is
>>>> ignore the link speed and duplex since they aren't valid.
>>>
>>> Ok for this.
>>>
>>>> To be completely correct, there
>>>> should be additional checks to prevent a slave that negotiates a
>>>> different speed from being activated.
>>>
>>> Looks like every changing in the link properties should cause LSC interrupt.
>>> In the bonding LCS interrupt you could handle and to deactivate the device.
>>> Also you should deal with the case of the first slave, what is happen if the
>> first slave has invalid link properties?
>>> How can you know that the speed\duplex_mode is invalid?
>>> Are we sure LACP mode can run with auto negotiation?
>>
>> Yes, I am pretty sure bonding doesn't get this right when the interfaces
>> aren't link up. While what bonding is doing is likely wrong, it doesn't mean
>> that the behavior of the PMDs are correct in leaving the link_status unset
>> until the first LSC interrupt.
>>
>> I plan to get around to looking at this bonding problem in a little bit. Luckily it
>> seems that we always tend to get matched links and even if bonding is
>> advertising the wrong aggregate speed and duplex we are find for now. It
>> wouldn't pass close inspection by a protocol analyzer though.
>>
>
> So, Are you going to fix it,
> If no, I think you can open a bug in Bugzilla.
Hi Matan, Chas,
What is the latest status of the patch?
And I guess there is another issue as well discussed here, is it still valid?
Thanks,
ferruh
More information about the dev
mailing list