Skip site navigation (1)Skip section navigation (2)
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>