Changing the MTU on a lagg device

[John-Mark Gurney]

Ravi Pokala wrote this message on Mon, Feb 09, 2015 at 16:10 +0000:
> -----Original Message-----
> From: Navdeep Parhar <np at FreeBSD.org>
> Date: 2015-02-07, Saturday at 08:30
> To: Ravi Pokala <rpokala at panasas.com>
> Cc: John-Mark Gurney <jmg at funkthat.com>, "freebsd-hackers at freebsd.org"
> <freebsd-hackers at 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."