Date: Mon, 9 Feb 2015 16:10:01 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: Navdeep Parhar <np@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, John-Mark Gurney <jmg@funkthat.com> Subject: Re: Changing the MTU on a lagg device Message-ID: <D0FE1745.12C785%rpokala@panasas.com> In-Reply-To: <20150207163028.GA4965@ox> References: <D0FABB8B.12C626%rpokala@panasas.com> <20150207051012.GH58410@funkthat.com> <D0FADE7D.12C6BE%rpokala@panasas.com> <20150207163028.GA4965@ox>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: Navdeep Parhar <np@FreeBSD.org> Date: 2015-02-07, Saturday at 08:30 To: Ravi Pokala <rpokala@panasas.com> Cc: John-Mark Gurney <jmg@funkthat.com>, "freebsd-hackers@freebsd.org" <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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0FE1745.12C785%rpokala>