From: David Miller <davem@davemloft.net>
To: fw@strlen.de
Cc: netdev@vger.kernel.org, hannes@stressinduktion.org, edumazet@google.com
Subject: Re: [PATCH -next] net: preserve geometry of fragment sizes when forwarding
Date: Mon, 18 May 2015 15:39:22 -0400 (EDT) [thread overview]
Message-ID: <20150518.153922.1873846748456446294.davem@davemloft.net> (raw)
In-Reply-To: <1431032664-6478-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 7 May 2015 23:04:24 +0200
> There was interest in keeping geometry of original fragments on forward.
>
> This (re)enables this feature.
>
> on router with mtu 1500 on all interfaces and netfilter conntrack enabled:
...
> Caveat:
> This disables the optimization made in commit
> 3cc4949269e01f39443d0 ("ipv4: use skb coalescing in defragmentation") for
> everyone as soon as nf_defrag_ipv4 modules are loaded (conntrack defrag
> hooks earlier than ipv4 stacks own defragmentation for local delivery),
> and there is no way to easily determine if we will forward the skb at that
> stage.
>
> ip_fragment checks the size of the frag skbs vs. the outgoing device mtu
> before using them so if device mtu is smaller than the frag skb length
> the device mtu will be used instead for refragmentation.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Indeed, I agree that we should only modify the packet's geomtry if we
know it's to be locally delivered.
But paying the cost just because a netfilter module is loaded, that's
really heavy handed and shows really bad engineering on our part.
When I hear "happens when netfilter modules are loaded", it translates
into my head as "all the time". And for you it should too, because
effectively that's how the world operates.
next prev parent reply other threads:[~2015-05-18 19:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 21:04 [PATCH -next] net: preserve geometry of fragment sizes when forwarding Florian Westphal
2015-05-18 19:39 ` David Miller [this message]
2015-05-18 20:06 ` Florian Westphal
2015-05-18 20:28 ` David Miller
2015-05-18 20:40 ` Florian Westphal
2015-05-18 20:55 ` David Miller
2015-05-18 21:33 ` Florian Westphal
2015-05-18 22:50 ` Herbert Xu
2015-05-18 23:02 ` Florian Westphal
2015-05-18 23:20 ` Herbert Xu
2015-05-18 23:51 ` David Miller
2015-05-19 12:34 ` Florian Westphal
2015-05-19 19:34 ` Jay Vosburgh
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=20150518.153922.1873846748456446294.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=hannes@stressinduktion.org \
--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).