Date: Mon, 9 Feb 2015 18:33:12 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>, Navdeep Parhar <np@FreeBSD.org> Subject: Re: Changing the MTU on a lagg device Message-ID: <D0FE3C6A.12C7EA%rpokala@panasas.com> In-Reply-To: <20150209181909.GG1953@funkthat.com> References: <D0FABB8B.12C626%rpokala@panasas.com> <20150207051012.GH58410@funkthat.com> <D0FADE7D.12C6BE%rpokala@panasas.com> <20150207163028.GA4965@ox> <D0FE1745.12C785%rpokala@panasas.com> <20150209181909.GG1953@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: John-Mark Gurney <jmg@funkthat.com> Date: 2015-02-09, Monday at 10:19 To: Ravi Pokala <rpokala@panasas.com> Cc: Navdeep Parhar <np@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: Re: Changing the MTU on a lagg device >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... I considered as well, but I figured dropping to the lowest MTU that worked for all the components would be less disruptive than moving to the higher MTU and kicking out the failed components. I'm flexible on this; it seems to be a fairly rare corner-case, in which all options suck, so I'm happy to defer to others as to which option sucks least. :-) -Ravi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0FE3C6A.12C7EA%rpokala>