All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Florian Westphal <fw@strlen.de>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, hannes@stressinduktion.org,
	edumazet@google.com, herbert@gondor.apana.org.au
Subject: Re: [PATCH -next] net: preserve geometry of fragment sizes when forwarding
Date: Tue, 19 May 2015 12:34:12 -0700	[thread overview]
Message-ID: <6079.1432064052@nyx> (raw)
In-Reply-To: <20150519123415.GC5063@breakpoint.cc>

Florian Westphal <fw@strlen.de> wrote:
[...]
> cons: doesn't resolve hypothetical(?) router edge cases:
>   #1. if we'd receive e.g. fragment size 1000 and fragment size
>   200, where both fragments have DF bit set, we will currently
>   send a single 1200 byte DF packet, if outdevice has mtu >= 1200.
>
>   This is because ip_finish_output() only fragments if skb->len > mtu.
>
>   #2 iff we do refragment (e.g. out mtu is 1000), we re-create fragments
>   of size 1000 and 200, but DF bit gets lost in the process.
>
>Neither seems to be a big problem, #2 doesn't break end-to-end connectivity,
>and #1 doesn't seem to happen in practice; else we should have seen
>bug reports by now.  However, I do feel uneasy about it and think we should
>fix it.

	FWIW, I've seen Openstack-based network topologies with local
customizations to take advantage of #1 to deliberately avoid
refragmentation on bridge egress.  In this case, the bridge egress port
is a veth device, and the bridge-side veth mtu is set higher than the
veth peer's mtu, which is in a container.  The veth driver does not
check mtu on transmit, so this "works."

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

      reply	other threads:[~2015-05-19 19:34 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
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 [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=6079.1432064052@nyx \
    --to=jay.vosburgh@canonical.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=hannes@stressinduktion.org \
    --cc=herbert@gondor.apana.org.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.