On 29 March 2016 at 03:19, Lu, Wenzhuo <wenzhuo.lu at intel.com> wrote:
> Hi Marc, > > > > *From:* marc.sune at gmail.com [mailto:marc.sune at gmail.com] *On Behalf Of * > Marc > *Sent:* Monday, March 28, 2016 7:03 PM > *To:* Lu, Wenzhuo > *Cc:* dev at dpdk.org > *Subject:* Re: e1000: randomly loosing link change events triggered by > the peer > > > > > > > > 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). > > [Wenzhuo] I don?t have a 15a2 on hand. I?m using i350. I haven?t hit the > same problem. As you said it?s random. Would you like to let me know why > you think it?s general not NIC specific? Thanks. > It was random but it was happening very frequently. > > > 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. > > [Wenzhuo] Would you like to give me a patch of your change? Thanks. > Unfortunately I checkedout that code, as it was a hack to test, but it was as simple as calling check_all_ports_link_status() in print_stats() for l2fwd example, so that was reporting link status periodically. Marc > > > 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 >
