From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) by dpdk.org (Postfix) with ESMTP id 49AD67EC4 for ; Fri, 7 Nov 2014 17:27:32 +0100 (CET) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3427.houston.hp.com (Postfix) with ESMTPS id 034A2B9; Fri, 7 Nov 2014 16:37:04 +0000 (UTC) Received: from G4W6306.americas.hpqcorp.net (16.210.26.231) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 7 Nov 2014 16:36:09 +0000 Received: from G4W3231.americas.hpqcorp.net ([169.254.11.88]) by G4W6306.americas.hpqcorp.net ([16.210.26.231]) with mapi id 14.03.0169.001; Fri, 7 Nov 2014 16:36:09 +0000 From: "Roberts, Lee A." To: "thomas.monjalon@6wind.com" Thread-Topic: issue with ixgbevf speed/duplex introduced with commit 8ef32003772a14c61c70b540e41c259c482c2fb6 Thread-Index: Ac/6pyJIQGqj83pBTcmWoKu9DbMqPg== Date: Fri, 7 Nov 2014 16:36:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.16] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: [dpdk-dev] issue with ixgbevf speed/duplex introduced with commit 8ef32003772a14c61c70b540e41c259c482c2fb6 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: Fri, 07 Nov 2014 16:27:32 -0000 Thomas, I'm seeing an issue with ixgbevf speed/duplex reporting that appears to hav= e been introduced with commit 8ef32003772a14c61c70b540e41c259c482c2fb6 (http://www.dpdk.org/browse= /dpdk/commit/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c?id=3D8ef32003772a14c61c7= 0b540e41c259c482c2fb6) The issue I'm seeing seems to involve the following code. If I'm reading t= his correctly, one sets "mac->get_link_status =3D true" if the port is not OK, where "true= " means that one still needs to get the link status. Due to the added test "if (!mac->get_l= ink_status)", one branches to the early exit if mac->get_link_status is false---meaning w= e have already obtained the link status---instead of continuing with the analysis in the f= unction body. - if (!(hw->mbx.ops.check_for_rst(hw, 0))) { - *link_up =3D false; - *speed =3D 0; - return -1; - } + /* If we were hit with a reset drop the link */ + if (!mbx->ops.check_for_rst(hw, 0) || !mbx->timeout) + mac->get_link_status =3D true; - links_reg =3D IXGBE_VFREAD_REG(hw, IXGBE_VFLINKS); + if (!mac->get_link_status) + goto out; When I run "testpmd" on ixgbevf ports either in the host OS or passed through to a virtual machine, "testpmd" reports that the ixgbevf ports have "speed 100 Mbps - half-duplex". With the previous code (or with my patch), "testpmd" reports "speed 10000 Mbps - full-duplex". - Lee Roberts