[dpdk-dev] e1000: randomly loosing link change events triggered by the peer

[Marc]

On 28 March 2016 at 03:54, Lu, Wenzhuo <wenzhuo.lu at intel.com> wrote:

> Hi Marc
>
>
>
> *From:* Marc Sune [mailto:marcdevel at gmail.com]
> *Sent:* Saturday, March 26, 2016 9:43 AM
> *To:* dev at dpdk.org; Lu, Wenzhuo
> *Subject:* e1000: randomly loosing link change events triggered by the
> peer
>
>
>
> I found that in the current HEAD in master testing it with an I218-LM in
> autoneg mode, when link is forced to be renegociated by the peer (e.g. via
> ethtool on a peer Linux box) _some_ change events are lost.
>
>
>
> It is quite random, but it seems to happen more while changing the speed
> than when changing the duplex mode.
>
>
>
> However, when one or more link change events have been lost and the phy
> medium is disconnected and reconnected, the link speed and duplex mode are
> then correctly updated.
>
>
>
> Marc
>
>
>
> [Wenzhuo] Thanks for let us know this issue. May I ask some questions? Do
> you mean this NIC 0x155A?
>

0x15A2,  I218-LM (rev 03)

EAL: PCI device 0000:00:19.0 on NUMA socket -1
EAL:   probe driver: 8086:15a2 rte_em_pmd
EAL:   PCI memory mapped at 0x7f85cf400000
EAL:   PCI memory mapped at 0x7f85cf420000
PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x15a2

I think this is not a NIC issue, but a general problem of the driver (or em
code).


> About how to reproduce this problem, you mean use these CLIs, ethtool –s
> xxx advertise xxx, ethtool –s xxx duplex half/full, to change the peer
> port’s configuration?
>

Correct. I modified l2fwd to check link status and print it on each port
stats print iteration. Then from the peer I modified the link properties
via ethtool.

The result is that transitions from autoneg speeds and/or duplex mode
settings are randomly not detected (rte_eth_link in rte_eth_dev_data is not
updated), and it prints not-up-to-date state.

Marc