From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) by dpdk.org (Postfix) with ESMTP id 26D782C4B for ; Mon, 28 Mar 2016 13:03:17 +0200 (CEST) Received: by mail-lf0-f66.google.com with SMTP id y184so3751832lfd.3 for ; Mon, 28 Mar 2016 04:03:17 -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=kZrzX6D7sP8pXZcNwJGRJhhLcmVkB4Nhz19UIsrJ0qg=; b=QO+o0tUL0sSqpUHEOHNQHN+l1nytF89gH5dei/Oaun4Db/pC/zgddJ09rC7ECjUxNl atDK2kGEvYFfs8inPoNiRZTnWVcCMfkTlvP9/goA2Nnq/UHS7F9YH0s3FiQeTllG5ypF q79TTjskK2qG0+pM3zYqSgw2V71/T4+xSaKUO8fYBb8rCMaAGjWr7DsJnXWeIwLPCeQX 0M7V0iALL9D+biiypiDxEMFEuTodvZ4MOF4XJkD78g9yPL395h2J9APs3YufzAf0+9xy ws8zMgDbC+GOFEJI1YgqVYBDj05m4YZ9LA0sj4sGV0PZVzomFxE/R1iSS+eIQWygZuDR 73vQ== 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=kZrzX6D7sP8pXZcNwJGRJhhLcmVkB4Nhz19UIsrJ0qg=; b=SJzaLt9JWzxBFoaY/M786RGstDrF1ei4U1cpy4rulGvhuQIv/bF82zci9Uwzzb5l2N QyVpGKAtNX765ywranr8xTmsfKDBOyyi0qGRBMqvMn4Wqg6n/vpGBqEfRo/IjGv6c+Zx 7UohnI9cC0ORYkk6NbkOeIf12Tv0tnAGTBJTYWJvx5tG09peQTMob8W4yh1VkgILc6A6 QmdF/YPNkLcG0x9QPFwL6emw7ye3wELpoF3rqBDaRldNoQNREMj5s/NUH4dd71wfofcF fjh9jUKZPuNZ/tMs/n0CpR3TMbQ5BMlZkf44tjS9xbHBsHD93LKJuzHSmWZm6ov6blOE kUCw== X-Gm-Message-State: AD7BkJItoHfQBx8KCHsAUHaxvvdhU5ZMgdlCntyPt1teEHDBpcrE5pSNMiBWYJQ5kAtSqgsJhwWhb5zldPTHaw== X-Received: by 10.25.15.80 with SMTP id e77mr9994419lfi.37.1459162996758; Mon, 28 Mar 2016 04:03:16 -0700 (PDT) MIME-Version: 1.0 Sender: marc.sune@gmail.com Received: by 10.112.155.196 with HTTP; Mon, 28 Mar 2016 04:02:57 -0700 (PDT) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090343F665@shsmsx102.ccr.corp.intel.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09090343F665@shsmsx102.ccr.corp.intel.com> From: Marc Date: Mon, 28 Mar 2016 13:02:57 +0200 X-Google-Sender-Auth: yIHRnn3Rm-BDTBU4h6OJUxYWdK0 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: Mon, 28 Mar 2016 11:03:17 -0000 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). > 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. 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