All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Rick Jones <rick.jones2@hp.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] vlan: propogate MTU changes
Date: Tue, 07 Oct 2008 01:02:08 +0200	[thread overview]
Message-ID: <48EA98F0.40302@trash.net> (raw)
In-Reply-To: <48EA964A.6060503@hp.com>

Rick Jones wrote:
> Patrick McHardy wrote:
>> 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?

The traffic actually shouldn't stop since the MTU isn't enforced by
the lower layers and also usually not by the driver. So I feel unable
to make a policy decision when both views don't seem unreasonable.
Especially given the fact that the "more suprising" behaviour so far
has been our default.

> 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.

Thats assuming that the VLAN device is actually restricted by the
ethernet device settings. I don't know if its always not the case,
but I'm pretty sure it usually isn't. Which means there's no real
need for an operational state wrt. MTUs.

  reply	other threads:[~2008-10-06 23:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06 15:30 [PATCH] vlan: propogate MTU changes Stephen Hemminger
2008-10-06 16:02 ` Patrick McHardy
2008-10-06 17:54   ` Stephen Hemminger
2008-10-06 18:25     ` [PATCH] vlan: propogate MTU changes (v2) Stephen Hemminger
2008-10-06 18:45       ` Duyck, Alexander H
2008-10-06 19:20         ` Ben Hutchings
2008-10-06 22:53       ` Patrick McHardy
2008-10-06 22:33     ` [PATCH] vlan: propogate MTU changes Patrick McHardy
2008-10-06 22:50       ` Rick Jones
2008-10-06 23:02         ` Patrick McHardy [this message]
2008-10-06 23:04           ` Patrick McHardy
2008-10-06 23:18           ` Rick Jones
2008-10-06 23:33             ` Patrick McHardy
2008-10-07 23:05               ` David Miller
2008-10-08 11:53               ` Patrick McHardy
2008-10-06 20:14 ` Krzysztof Oledzki
2008-10-06 22:38   ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EA98F0.40302@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --cc=shemminger@vyatta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.