From patchwork Thu Oct 13 17:21:23 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Flavio Leitner X-Patchwork-Id: 119573 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id B8D10B71DF for ; Fri, 14 Oct 2011 04:21:54 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756204Ab1JMRVt (ORCPT ); Thu, 13 Oct 2011 13:21:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17801 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753711Ab1JMRVt (ORCPT ); Thu, 13 Oct 2011 13:21:49 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9DHLU1o031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2011 13:21:30 -0400 Received: from localhost (ovpn-113-120.phx2.redhat.com [10.3.113.120]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9DHLTxi003227; Thu, 13 Oct 2011 13:21:30 -0400 From: Flavio Leitner To: netdev Cc: Jay Vosburgh , Andy Gospodarek , Flavio Leitner Subject: [PATCH net-next] bonding: fix wrong port enabling in 802.3ad Date: Thu, 13 Oct 2011 14:21:23 -0300 Message-Id: <1318526483-16073-1-git-send-email-fbl@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The port shouldn't be enabled unless its current MUX state is DISTRIBUTING which is correctly handled by ad_mux_machine(), otherwise the packet sent can be lost because the other end may not be ready. The issue happens on every port initialization, but as the ports are expected to move quickly to DISTRIBUTING, it doesn't cause much problem. However, it does cause constant packet loss if the other peer has the port configured to stay in STANDBY (i.e. SYNC set to OFF). Signed-off-by: Flavio Leitner --- The comments there suggests it was a workaround for losses of link events, but I couldn't track the changelog as it seems to be pretty old. Thus, as all the link notification stuff has been improved a lot, maybe this is not an issue anymore. At least, I didn't find any problem while unplugging/plugging cables here. drivers/net/bonding/bond_3ad.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c index 47b928e..b33c099 100644 --- a/drivers/net/bonding/bond_3ad.c +++ b/drivers/net/bonding/bond_3ad.c @@ -1135,13 +1135,6 @@ static void ad_rx_machine(struct lacpdu *lacpdu, struct port *port) __record_pdu(lacpdu, port); port->sm_rx_timer_counter = __ad_timer_to_ticks(AD_CURRENT_WHILE_TIMER, (u16)(port->actor_oper_port_state & AD_STATE_LACP_TIMEOUT)); port->actor_oper_port_state &= ~AD_STATE_EXPIRED; - // verify that if the aggregator is enabled, the port is enabled too. - //(because if the link goes down for a short time, the 802.3ad will not - // catch it, and the port will continue to be disabled) - if (port->aggregator - && port->aggregator->is_active - && !__port_is_enabled(port)) - __enable_port(port); break; default: //to silence the compiler break;