From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Oussama Ghorbel <oghorbell@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ou.ghorbel@gmail.com
Subject: Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
Date: Sun, 29 Sep 2013 17:45:46 +0200 [thread overview]
Message-ID: <20130929154546.GA10771@order.stressinduktion.org> (raw)
In-Reply-To: <CA+ev270d2Ztq9i34Lv9U15y1TbH7W-fioXFn-Q_sJd5F4biHuw@mail.gmail.com>
On Sun, Sep 29, 2013 at 10:40:11AM +0100, Oussama Ghorbel wrote:
> On Fri, Sep 27, 2013 at 6:03 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > Ok, let's go with one function per protocol type. Seems easier.
> >
> > It seems to get more hairy, because it depends on the tunnel driver if the
> > prepended ip header is accounted in hard_header_len. :/
> >
> > I don't know if it works out cleanly. Otherwise I would be ok if the checks
> > just get repeated in ip6_tunnel and leave the rest as-is.
> >
> Yes, It will be the clean way to do it.
Fine. :)
> >
> > Linux currently cannot create "jumbograms" (only the receiving side
> > is supported).
> >
> I understand, but what are the benefit from this limit or the harm
> from not specifying it?
> Please check this comment from eth.c
>
> /**
> * eth_change_mtu - set new MTU size
> * @dev: network device
> * @new_mtu: new Maximum Transfer Unit
> *
> * Allow changing MTU size. Needs to be overridden for devices
> * supporting jumbo frames.
> */
> int eth_change_mtu(struct net_device *dev, int new_mtu)
Hmm, I cannot judge without the full patch. Will it be applicable
to all net_devices or just ethernet ones? The name could be a bit
misleading. Remindes me a lot of dev_set_mtu based on the signature, btw.
> So wouldn't be a good idea to let our function open for jumbo frames...?
Hm, we can document the fact that the function would needed to be updated in
that case. But we should not allow to set a mtu which would require jumbograms
currently.
Greetings,
Hannes
next prev parent reply other threads:[~2013-09-29 15:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 14:51 Oussama Ghorbel
2013-09-27 8:37 ` Hannes Frederic Sowa
2013-09-27 10:45 ` Oussama Ghorbel
2013-09-27 10:58 ` Hannes Frederic Sowa
2013-09-27 16:36 ` Oussama Ghorbel
2013-09-27 17:03 ` Hannes Frederic Sowa
2013-09-29 9:40 ` Oussama Ghorbel
2013-09-29 15:45 ` Hannes Frederic Sowa [this message]
2013-09-29 16:33 ` Oussama Ghorbel
2013-10-03 12:37 ` Oussama Ghorbel
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=20130929154546.GA10771@order.stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oghorbell@gmail.com \
--cc=ou.ghorbel@gmail.com \
--cc=yoshfuji@linux-ipv6.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
all inboxes | Powered by JetHome®