From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 18:19:13 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 DBAA8AA3; Mon, 9 Feb 2015 18:19:12 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B557C926; Mon, 9 Feb 2015 18:19:12 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t19IJBnp018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 10:19:11 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t19IJ98m018331; Mon, 9 Feb 2015 10:19:09 -0800 (PST) (envelope-from jmg) Date: Mon, 9 Feb 2015 10:19:09 -0800 From: John-Mark Gurney To: "Pokala, Ravi" Subject: Re: Changing the MTU on a lagg device Message-ID: <20150209181909.GG1953@funkthat.com> References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 09 Feb 2015 10:19:11 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , Navdeep Parhar 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 18:19:13 -0000 Ravi Pokala wrote this message on Mon, Feb 09, 2015 at 16:10 +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... > >> > >> 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? Hate to suggest making this more complicated, but we should leave lagg in as consistent state as possible... Which IMO, though very surprising, is kicking out the failed component... Leaving a mixed MTU which could drop packets, but somewhat work seems worse... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."