From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 7 23:20:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0F199A6 for ; Sat, 7 Feb 2015 23:20:33 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8EB95E5 for ; Sat, 7 Feb 2015 23:20:33 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id B73FECEADA; Sat, 7 Feb 2015 15:20:26 -0800 (PST) Date: Sat, 7 Feb 2015 15:20:26 -0800 From: hiren panchasara To: "Pokala, Ravi" , John-Mark Gurney , "freebsd-hackers@freebsd.org" Subject: Re: Changing the MTU on a lagg device Message-ID: <20150207232026.GA10438@strugglingcoder.info> References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20150207163028.GA4965@ox> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 23:20:34 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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... > >=20 > > Which is exactly what our code does. :-) >=20 > 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 >=20 > Regards, > Navdeep >=20 > >=20 > > 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. > >=20 > > -Ravi > >=20 > > -----Original Message----- > > From: John-Mark Gurney > > Date: 2015-02-06, Friday at 21:10 > > To: Ravi Pokala > > Cc: "freebsd-hackers@freebsd.org" > > Subject: Re: Changing the MTU on a lagg device > >=20 > > >Ravi Pokala wrote this message on Sat, Feb 07, 2015 at 02:42 +0000: > > >> Hi folks, > > >>=20 > > >> 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: > > >>=20 > > >> 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 > > >>=20 > > >> It would be nice if this could be done with a single command: > > >>=20 > > >> 1) ifconfig lagg0 mtu 9000 > > >>=20 > > >> Panasas implemented that functionality for our older base FreeBSD, a= nd > > >> we're looking to port it forward and push it upstream. However, it l= ooks > > >> like someone thought about this case and explicitly decided not to do > > >>it; > > >> if_lagg.c has: > > >>=20 > > >> case SIOCSIFMTU: > > >> /* Do not allow the MTU to be changed once joined */ > > >> error =3D EINVAL; > > >> break; > > >>=20 > > >>=20 > > >> Does anyone know why that is? Would anyone object to a patch that le= ts > > >>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... > > > > > >--=20 > > > John-Mark Gurney Voice: +1 415 225 5579 > > > > > > "All that I will do, has been done, All that I have, has not." > >=20 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJU1p26XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/ldCIH/2LP6dQzsORQsCqhshJQMSF9 ddtOaTlbqo8SaUQgHTGQAGiM1aS9TFNPW1Y/weoCTO+jG2c/Ulr78pzVtOO+7OQL Y/drMMl70kXMErM9SeC1S24c2OYIxXeRuphLOBaGn1PSyYxQLk/zppjvta3pfbm1 d3dkfJQA5pzQA8l6QXZfi0nkurP7rsQIUoAhFtZeojRB1/inwWgnVxULOQwW+aXu rBPVCOpLrx35od0JwzFenW/E0fk7M7Yuyej6kko+2tdNYH8f++ZWR2md7FNTwi+u QPCQWkFCk8c+IBA6swR7SzP6BstlRcQ7X0roQJJg/idjc6eOd/Mki6HA/jSolEw= =aep0 -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8--