lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 06 Oct 2008 15:50:50 -0700 From: Rick Jones <rick.jones2@...com> To: Patrick McHardy <kaber@...sh.net> CC: Stephen Hemminger <shemminger@...tta.com>, "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: [PATCH] vlan: propogate MTU changes Patrick McHardy wrote: > Stephen Hemminger wrote: > >> On Mon, 06 Oct 2008 18:02:39 +0200 >> Patrick McHardy <kaber@...sh.net> wrote: >> >>> - the stack in fact doesn't require us to reduce the MTU of a VLAN >>> device as long as its within the physically possible MTU. >> >> >> I think it should call change_mtu so userspace gets notified about both >> changes. > > > Agreed. But the question when to do automatic adjustments remains. A matter of interpretation of the principle of least surprise right? Which is less surprising - that a VLAN's MTU drops to match that of the physical interface or that some traffic on the VLAN stops when the physical interface's MTU drops? If physical interface MTUs are going to be bouncing around and VLANs get their MTUs changed then perhaps a VLAN needs both a desired and actual MTU setting. The VLAN's interface would then be the minimum of the desired and actual MTU. I suppose it isn't too unlike having both an administrative (desired) and operational (actual) interface state. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists