From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 16:10:11 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CB388A; Mon, 9 Feb 2015 16:10:11 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0085.outbound.protection.outlook.com [157.56.111.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5133C751; Mon, 9 Feb 2015 16:10:10 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 9 Feb 2015 16:10:02 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0075.002; Mon, 9 Feb 2015 16:10:02 +0000 From: "Pokala, Ravi" To: Navdeep Parhar Subject: Re: Changing the MTU on a lagg device Thread-Topic: Changing the MTU on a lagg device Thread-Index: AQHQQn+0qPs6AFh2xkSO1q7r/b61upzko7MA//9+dwCAAT+aAIACmNSA Date: Mon, 9 Feb 2015 16:10:01 +0000 Message-ID: References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> In-Reply-To: <20150207163028.GA4965@ox> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0942; x-forefront-prvs: 04825EA361 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(13464003)(377424004)(24454002)(164054003)(51704005)(2656002)(50986999)(19580405001)(66066001)(62966003)(76176999)(93886004)(36756003)(19580395003)(54356999)(87936001)(102836002)(86362001)(2950100001)(40100003)(110136001)(92566002)(122556002)(106116001)(77156002)(2900100001)(46102003)(99286002)(83506001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <542D39F19E912548A87CABE049EA9B71@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2015 16:10:01.8263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0942 Cc: "freebsd-hackers@freebsd.org" , John-Mark Gurney X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:10:12 -0000 -----Original Message----- From: Navdeep Parhar Date: 2015-02-07, Saturday at 08:30 To: Ravi Pokala Cc: John-Mark Gurney , "freebsd-hackers@freebsd.org" Subject: Re: Changing the MTU on a lagg device >On Sat, Feb 07, 2015 at 05:26:36AM +0000, Pokala, Ravi wrote: >> > So, to do it, you'd need to try to change all the ports mtu, and if >>any of them fail, you need to revert all of them back to the original >>mtu... >>=20 >> Which is exactly what our code does. :-) > >And if reverting it fails then you end up with the old MTU on some >interfaces and the new MTU on others. Very unlikely, but possible. >if_lagg may have been written the way it is to avoid dealing with >failures to revert the MTU. Hi Navdeep, That's a fair point, but I'm not sure that's really any different from the way things currently work. With the current code, the case you're describing would look like this: 1) Component interfaces removed from LAGG 2) Attempt to change MTU on one or more component interfaces failed 3) Attempt to revert MTU change on one or more component interfaces also failed 4) LAGG is left in an unusable state, with no component interfaces With the proposed code, it would look like this: 1) Attempt to change MTU on one or more component interfaces failed 2) Attempt to revert MTU change on one or more component interfaces also failed 3) LAGG is left in an unusable state, with non-uniform component interfaces Either way, the LAGG is down. I should also note that I wouldn't change the MTU of the LAGG itself until after all the component interfaces were successfully changed, so that would at least prevent it from trying to send over-sized packets to the component interfaces. Although, now that I think of it, that statement is only true if we were trying to *increase* the MTU; in the case that we're trying to *decrease* it, the old value would be larger. So, how about this - if there's a failure, I set the LAGG MTU to the lowest MTU of any of the components? Does that sound reasonable? Thanks, Ravi >Regards, >Navdeep