From patchwork Sat Jan 25 04:55:09 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ding Tianhong X-Patchwork-Id: 314112 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 7A7132C0099 for ; Sat, 25 Jan 2014 15:58:49 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751429AbaAYE6q (ORCPT ); Fri, 24 Jan 2014 23:58:46 -0500 Received: from szxga01-in.huawei.com ([119.145.14.64]:2912 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146AbaAYE6o (ORCPT ); Fri, 24 Jan 2014 23:58:44 -0500 Received: from 172.24.2.119 (EHLO szxeml213-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQO22402; Sat, 25 Jan 2014 12:58:19 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Jan 2014 12:55:12 +0800 Received: from [127.0.0.1] (10.177.22.246) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server id 14.3.158.1; Sat, 25 Jan 2014 12:55:12 +0800 Message-ID: <52E343AD.3080402@huawei.com> Date: Sat, 25 Jan 2014 12:55:09 +0800 From: Ding Tianhong User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , "David S. Miller" , Netdev Subject: [PATCH RESEND net-next] bonding: don't permit slaves to change their mtu independently X-Originating-IP: [10.177.22.246] X-CFilter-Loop: Reflected Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org I have come to a conclusion by testing all modes for mtu changing: 1). If the slaves support changing mtu and no need to restart the device, just like virtual nic, the master will not lost any packages for all mode. 2). If the slaves support changing mtu and need to restart the device, just like Intel 82599, the AB, 802.3, ALB and TLB mode may lost packages, but other modes could work well. The reason is that when the slave's mtu has been changed, the slave's hw will restart, if the slave is current active slave, the master may set the slave to backup state and reselect a new slave, after the reselect processing, the master could work again, but if in load-balance mode, the master could select another active slave to send and recv packages. So the best way to fix the problem is don't permit slave to change their mtu independently. Cc: Jay Vosburgh Cc: Veaceslav Falico Cc: Andy Gospodarek Signed-off-by: Ding Tianhong --- drivers/net/bonding/bond_main.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 2ca949f..e127031c 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -2808,20 +2808,12 @@ static int bond_slave_netdev_event(unsigned long event, * ... Or is it this? */ break; - case NETDEV_CHANGEMTU: - /* - * TODO: Should slaves be allowed to - * independently alter their MTU? For - * an active-backup bond, slaves need - * not be the same type of device, so - * MTUs may vary. For other modes, - * slaves arguably should have the - * same MTUs. To do this, we'd need to - * take over the slave's change_mtu - * function for the duration of their - * servitude. + case NETDEV_PRECHANGEMTU: + /* The master and slaves should have the + * same mtu, so don't permit slaves to + * change their mtu independently. */ - break; + return NOTIFY_BAD; case NETDEV_CHANGENAME: /* we don't care if we don't have primary set */ if (!USES_PRIMARY(bond->params.mode) ||