From: Jarod Wilson <jarod@redhat.com>
To: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: Minimum MTU Mess
Date: Mon, 12 Sep 2016 10:31:10 -0400 [thread overview]
Message-ID: <20160912143110.GN20632@redhat.com> (raw)
In-Reply-To: <08e44341-cfcd-5644-8e23-f7348de376b2@miraclelinux.com>
On Mon, Sep 12, 2016 at 11:59:41AM +0900, YOSHIFUJI Hideaki wrote:
>
>
> Jarod Wilson wrote:
> > On Tue, Sep 06, 2016 at 04:55:29PM -0700, David Miller wrote:
> >> From: Jarod Wilson <jarod@redhat.com>
> >> Date: Fri, 2 Sep 2016 13:07:42 -0400
> >>
> >>> In any case, the number of "mtu < 68" and "#define FOO_MIN_MTU 68", or
> >>> variations thereof, under drivers/net/ is kind of crazy.
> >>
> >> Agreed, we can have a default and let the different cases provide
> >> overrides.
> >>
> >> Mostly what to do here is a function of the hardware though.
> >
> > So I've been tinkering with this some, and it looks like having both
> > centralized min and max checking could be useful here. I'm hacking away at
> > drivers now, but the basis of all this would potentially look about like
> > the patch below, and each device would have to set dev->m{in,ax}_mtu one
> > way or another. Drivers using alloc_etherdev and/or ether_setup would get
> > the "default" values, and then they can be overridden. Probably need
> > something to make sure dev->max_mtu isn't set to 0 though...
> >
> > Possibly on the right track here, or might there be a better way to
> > approach this?
> >
> > diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
> > index 117d02e..864d6f2 100644
> > --- a/include/uapi/linux/if_ether.h
> > +++ b/include/uapi/linux/if_ether.h
> > @@ -35,6 +35,8 @@
> > #define ETH_FRAME_LEN 1514 /* Max. octets in frame sans FCS */
> > #define ETH_FCS_LEN 4 /* Octets in the FCS */
> >
> > +#define ETH_MIN_MTU 68 /* Min IPv4 MTU per RFC791 */
> > +
> > /*
> > * These are the defined Ethernet Protocol ID's.
> > */
>
> Why don't we disable IPv4 if the MTU is lower than this value
> as we do for IPv6?
What will you be left with that is actually usable? Quite a few NIC
drivers already enforce this as a minimum MTU, and for drivers that really
want to allow less, they just set min_mtu to whatever they like. I'm
actually aiming to be 100% functionally identical wrt all existing minimum
mtu checks already in existence, just trying to improve how they're done.
--
Jarod Wilson
jarod@redhat.com
prev parent reply other threads:[~2016-09-12 14:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 17:07 Minimum MTU Mess Jarod Wilson
2016-09-06 16:50 ` [PATCH net-next] sfc: check MTU against minimum threshold Bert Kenward
2016-09-06 21:31 ` Jarod Wilson
2016-09-06 23:54 ` David Miller
2016-09-06 23:55 ` Minimum MTU Mess David Miller
2016-09-07 19:53 ` Jarod Wilson
2016-09-07 20:31 ` Andrew Lunn
2016-09-07 23:43 ` Jarod Wilson
2016-09-08 1:24 ` Andrew Lunn
2016-09-09 18:05 ` Jarod Wilson
2016-09-12 2:41 ` Andrew Lunn
2016-09-12 14:27 ` Jarod Wilson
2016-09-07 20:35 ` Stephen Hemminger
2016-09-07 23:44 ` Jarod Wilson
2016-09-12 2:59 ` YOSHIFUJI Hideaki
2016-09-12 14:31 ` Jarod Wilson [this message]
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=20160912143110.GN20632@redhat.com \
--to=jarod@redhat.com \
--cc=davem@davemloft.net \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=netdev@vger.kernel.org \
/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).