netdev - Re: [PATCH] vlan: propogate MTU changes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48EA964A.6060503@hp.com>
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