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:33:47 +0200 [thread overview]
Message-ID: <48EAA05B.20004@trash.net> (raw)
In-Reply-To: <48EA9CCC.2050505@hp.com>
Rick Jones wrote:
> Patrick McHardy wrote:
>> 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.
>
> Does changing the MTU on a physical interface not change the size frame
> the NIC itself will be willing to accept?
IIRC a lot of the simpler ones just use the default eth_setup change_mtu
callback and the ones that have their one (just had a very brief look at
sky2, tg3 and e1000) only seem to use it indirectly for enabling jumbo
frame support and (e1000) memory allocation.
So I guess what we should do in case of the MTU depends on what we can
expect from the majority of hardware. If its just some older drivers
which can be reasonably expected to handle larger frames we should cap
at the maximum of the real device and maybe introduce the "desired
mtu" you suggested. It would be useful if people more familiar with
the drivers and hardware than me could comment on this.
next prev parent reply other threads:[~2008-10-06 23:33 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
2008-10-06 23:04 ` Patrick McHardy
2008-10-06 23:18 ` Rick Jones
2008-10-06 23:33 ` Patrick McHardy [this message]
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=48EAA05B.20004@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).