From: Steffen Klassert <steffen.klassert@secunet.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 2/5] ipv4: Kill ip_rt_frag_needed().
Date: Tue, 12 Jun 2012 13:44:40 +0200 [thread overview]
Message-ID: <20120612114440.GM27795@secunet.com> (raw)
In-Reply-To: <20120611.160258.866525532025442350.davem@davemloft.net>
On Mon, Jun 11, 2012 at 04:02:58PM -0700, David Miller wrote:
>
> Here below is the kind of patch I was suggesting we make. I did a
> simple test to make sure the update MTU code path is taken in
> raw_err().
I can confirm that your patch restores the old behaviour of ping.
>
> But I'm having second thoughts about whether any of this is a good
> idea.
>
> UDP works by notifying userspace of PMTU events. And this is
> mandatory, if we're setting DF we have to get the user to decrease the
> size of it's datagram writes below the reported PMTU value.
>
> As a consequence I believe RAW sockets should also work via
> notifications.
>
> And therefore it can be argued that in neither case should we update
> the routing cache PMTU information.
Should be ok as long as all userspace applications that use UDP or
RAW sockets handle pmtu event notifications properly.
ping might be a special case, but now the behaviour of a big
sized ping (say 1400 byte on a network that has a router with
mtu 1300 along the path) with IP_PMTUDISC_WANT might depend on
whether the cached pmtu informations are updated by a recent
tcp connection.
If we had no tcp connection before, we see the behaviour that
I described in my first mail. All packets have the DF bit set.
If a tcp connection updated the cached pmtu informations recently,
the packets don't have the DF bit set. They are fragmented according
the cached pmtu informations instead.
Other applications that do not care for pmtu event notifications
might be in a similar situation. So perhaps we need the kind of
patch you are suggested.
next prev parent reply other threads:[~2012-06-12 11:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 9:29 [PATCH 2/5] ipv4: Kill ip_rt_frag_needed() David Miller
2012-06-11 11:16 ` Steffen Klassert
2012-06-11 11:20 ` David Miller
2012-06-11 11:28 ` David Miller
2012-06-11 11:42 ` Steffen Klassert
2012-06-11 23:02 ` David Miller
2012-06-12 11:44 ` Steffen Klassert [this message]
2012-06-12 20:33 ` David Miller
2012-06-13 4:22 ` David Miller
2012-06-13 8:01 ` Steffen Klassert
2012-06-13 9:42 ` David Miller
2012-06-13 10:07 ` Steffen Klassert
2012-06-13 10:22 ` David Miller
2012-06-14 5:35 ` Steffen Klassert
2012-06-14 5:42 ` David Miller
2012-06-14 5:58 ` Steffen Klassert
2012-06-14 5:59 ` David Miller
2012-06-14 6:36 ` Steffen Klassert
2012-06-14 6:54 ` David Miller
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=20120612114440.GM27795@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--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).