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

Marc marcdevel at gmail.com
Wed Mar 30 10:04:51 CEST 2016


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
>


More information about the dev mailing list