From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) by dpdk.org (Postfix) with ESMTP id B3AADB62 for ; Wed, 30 Mar 2016 10:05:11 +0200 (CEST) Received: by mail-lf0-f68.google.com with SMTP id v198so3896029lfd.0 for ; Wed, 30 Mar 2016 01:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XHBaWksrb7qgF+QsWXZekd3MEeXwsAnERXBC4x7mA9c=; b=ndl9K20PKEds5bmOo1lMsp+iSb5g2Z/VyaCQN0Ykpa1n5UZDOSKtXGgj/Ty9vWlo0r BEmCZAUPUNEJjN1JjxX2JpwI+MSfsrFenEI13nwdznMAo87L22lL9OYcq9SpMe5bP02p 7k/782GaGp+57315T0UuZigipDWHe07v2ks9DTgi420Nv5vajUIA1B+l2GYCUAYt/Z2V CV6ar2QWkjJzLgEJWIP518kOW02BdvCIod0LdJ8hX7jJfDsExuOsOEXv8Q6HS7Yjnl/5 c5jAKd5g0MPoFbU03rZXgMuXdIOBoYSDNUDDTfHyiUYTV3IaLRL+lDNp9AoX+SFAVpfR F5VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XHBaWksrb7qgF+QsWXZekd3MEeXwsAnERXBC4x7mA9c=; b=cQl55q+o39Gpu/51iNdm6q0hXj/dj0MNoQnJqAmzfFBSSGkS3E+l+XcYkGCk5vVAgP sQw/NGWbsEgKXaMLXytSPNzhs/UZ7fY3S70CKrG8noRiG7nEVs54WBO7/89HEmkbfHGX OLg6/Z5AfXvBBF0wrNxy94TtNH4LhxyekaT+Az3Jp4cACJNK6ZLl8EQ44yKkxVKZJrD4 L6bVpi19Fe35I10X4P6+BF3gWKhLXqvGOqt4zCaXkfI+p45ulcwod1tltXUgns7a044I xEqCe+5Rv1QAjxiGcTX8pQhv85ejrIVEZaYQc7+6CQY3ybpD9txyvjiX4tzvjemz4Di+ ohLg== X-Gm-Message-State: AD7BkJJXrG2iEYKJyjaxMspCmSGlpPg8VEz2O+kmjod/N1cc72QQzRFBih1PeMSkvyXD51tjcc8aZvVq9FiRww== X-Received: by 10.25.167.19 with SMTP id q19mr3161555lfe.24.1459325111403; Wed, 30 Mar 2016 01:05:11 -0700 (PDT) MIME-Version: 1.0 Sender: marc.sune@gmail.com Received: by 10.25.168.201 with HTTP; Wed, 30 Mar 2016 01:04:51 -0700 (PDT) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090343FA87@shsmsx102.ccr.corp.intel.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09090343F665@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09090343FA87@shsmsx102.ccr.corp.intel.com> From: Marc Date: Wed, 30 Mar 2016 10:04:51 +0200 X-Google-Sender-Auth: UWBWFURQqA8OLZyYRnAbNVlH-Ko Message-ID: To: "Lu, Wenzhuo" Cc: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] e1000: randomly loosing link change events triggered by the peer X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 08:05:12 -0000 On 29 March 2016 at 03:19, Lu, Wenzhuo wrote: > Hi Marc, > > > > *From:* marc.sune@gmail.com [mailto:marc.sune@gmail.com] *On Behalf Of * > Marc > *Sent:* Monday, March 28, 2016 7:03 PM > *To:* Lu, Wenzhuo > *Cc:* dev@dpdk.org > *Subject:* Re: e1000: randomly loosing link change events triggered by > the peer > > > > > > > > On 28 March 2016 at 03:54, Lu, Wenzhuo wrote: > > Hi Marc > > > > *From:* Marc Sune [mailto:marcdevel@gmail.com] > *Sent:* Saturday, March 26, 2016 9:43 AM > *To:* dev@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. vi= a > 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 ar= e > 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=3D0x8086 deviceID=3D0x15a2 > > > > I think this is not a NIC issue, but a general problem of the driver (or > em code). > > [Wenzhuo] I don=E2=80=99t have a 15a2 on hand. I=E2=80=99m using i350. I = haven=E2=80=99t hit the > same problem. As you said it=E2=80=99s random. Would you like to let me = know why > you think it=E2=80=99s 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 =E2= =80=93s > xxx advertise xxx, ethtool =E2=80=93s xxx duplex half/full, to change the= peer > port=E2=80=99s 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 n= ot > updated), and it prints not-up-to-date state. > > > > Marc >