Changing the MTU on a lagg device

[hiren panchasara]

On 02/07/15 at 08:30P, Navdeep Parhar wrote:
> 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.

If somehow the changes can manage atomicity of the operation without
much complexity, I'd like to see this in the tree.

cheers,
Hiren
> 
> Regards,
> Navdeep
> 
> > 
> > Right now, I only have the change against our older base FreeBSD; I'll
> > port it to -CURRENT and send out a patch when I have a few minutes
> > sometime this weekend.
> > 
> > -Ravi
> > 
> > -----Original Message-----
> > From: John-Mark Gurney <jmg at funkthat.com>
> > Date: 2015-02-06, Friday at 21:10
> > To: Ravi Pokala <rpokala at panasas.com>
> > Cc: "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>
> > Subject: Re: Changing the MTU on a lagg device
> > 
> > >Ravi Pokala wrote this message on Sat, Feb 07, 2015 at 02:42 +0000:
> > >> Hi folks,
> > >> 
> > >> Let's say you have lagg0, consisting of if0 and if1. If you want to
> > >>change
> > >> the MTU, you have to remove if0 and if1 from the lagg, change their
> > >>MTUs,
> > >> and add them back; that is:
> > >> 
> > >> 1) ifconfig lagg0 -laggport if0
> > >> 2) ifconfig lagg0 -laggport if1
> > >> 3) ifconfig if0 mtu 9000
> > >> 4) ifconfig if1 mtu 9000
> > >> 5) ifconfig lagg0 laggport if0
> > >> 6) ifconfig lagg0 laggport if1
> > >> 
> > >> It would be nice if this could be done with a single command:
> > >> 
> > >> 1) ifconfig lagg0 mtu 9000
> > >> 
> > >> Panasas implemented that functionality for our older base FreeBSD, and
> > >> we're looking to port it forward and push it upstream. However, it looks
> > >> like someone thought about this case and explicitly decided not to do
> > >>it;
> > >> if_lagg.c has:
> > >> 
> > >> 	case SIOCSIFMTU:
> > >> 		/* Do not allow the MTU to be changed once joined */
> > >> 		error = EINVAL;
> > >> 		break;
> > >> 
> > >> 
> > >> Does anyone know why that is? Would anyone object to a patch that lets
> > >>you
> > >> change the MTU on the lagg device, and having the lagg driver change it
> > >>on
> > >> all the component interfaces for you?
> > >
> > >If could be trying to deal w/ the issue if you ask for 16000 but one
> > >can do it, but the other can only handle 9000, how do you handle it?
> > >
> > >Just for fun, I just tried something similar.. lagg won't allow you
> > >to add a port that has a different (smaller or bigger) MTU than the
> > >first one added..
> > >
> > >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...
> > >
> > >-- 
> > >  John-Mark Gurney				Voice: +1 415 225 5579
> > >
> > >     "All that I will do, has been done, All that I have, has not."
> > 
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150207/8aee7d44/attachment.sig>