From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 996B2C5B57D for ; Tue, 2 Jul 2019 21:04:04 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 90916218B6 for ; Tue, 2 Jul 2019 21:04:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90916218B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=davemloft.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45dcDJ0ZVyzDq6Q for ; Wed, 3 Jul 2019 07:04:00 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=davemloft.net (client-ip=2620:137:e000::1:9; helo=shards.monkeyblade.net; envelope-from=davem@davemloft.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=davemloft.net Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45dc9l5wsBzDqMT for ; Wed, 3 Jul 2019 07:01:43 +1000 (AEST) Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::d71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id B61A21000133B; Tue, 2 Jul 2019 14:01:36 -0700 (PDT) Date: Tue, 02 Jul 2019 14:01:34 -0700 (PDT) Message-Id: <20190702.140134.1769484209181791824.davem@davemloft.net> To: tlfalcon@linux.ibm.com Subject: Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool From: David Miller In-Reply-To: <1561655353-17114-1-git-send-email-tlfalcon@linux.ibm.com> References: <1561655353-17114-1-git-send-email-tlfalcon@linux.ibm.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 02 Jul 2019 14:01:37 -0700 (PDT) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, bjking1@us.ibm.com, dnbanerg@us.ibm.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Thomas Falcon Date: Thu, 27 Jun 2019 12:09:13 -0500 > This patch resolves an issue with sensitive bonding modes > that require valid speed and duplex settings to function > properly. Currently, the adapter will report that device > speed and duplex is unknown if the communication link > with firmware is unavailable. This decision can break LACP > configurations if the timing is right. > > For example, if invalid speeds are reported, the slave > device's link state is set to a transitional "fail" state > and the LACP port is disabled. However, if valid speeds > are reported later but the link state has not been altered, > the LACP port will remain disabled. If the link state then > transitions back to "up" from "fail," it results in a state > such that the slave reports valid speed/duplex and is up, > but the LACP port will remain disabled. > > Workaround this by reporting the last recorded speed > and duplex settings unless the device has never been > activated. In that case or when the hypervisor gives > invalid values, continue to report unknown speed or > duplex to ethtool. > > Signed-off-by: Thomas Falcon Like Andrew, I have my conerns about this. If the firmware is unavailable, the link is effectively down. So you should report link down and unknown link parameters. Bonding and LACP should do the right thing when the firwmare is reachable again after the migration and the link goes back up. If bonding/LACP isn't doing that, then the bug is there.