All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Killian De Volder <killian.de.volder@scarlet.be>
Cc: annie.li@oracle.com, xen-devel@lists.xen.org
Subject: Re: TCP Segment offloading + DF
Date: Fri, 30 Nov 2012 11:33:42 -0500	[thread overview]
Message-ID: <20121130163339.GC5481@localhost.localdomain> (raw)
In-Reply-To: <50A25798.90100@scarlet.be>

On Tue, Nov 13, 2012 at 03:22:16PM +0100, Killian De Volder wrote:
> Hello,
> 
> I don't know if TCO is supported for XEN_NETDEV_FRONTED in kernel 3.1.6,
> however I found an issue.
> 
> I had to track down an issue today:
> Packet from a local machine didn't get routed to the internet.
> After long searching I found the issue:
> 
> The TCP-Segmentation-offloading assembles fragments with Do Not Fragment set.
> This introduces issues when the packet is to be rerouted trough a router.
> 
> Situation:
> 
> DOM0
>  |->Bridge 1 - MTU 1500
>  |    |-> PHY - eth0
>  |    |-> VIF - Dom1
>  |    \-> VIF - Dom2 (router)
>  |
>  \->Bridge 2 - MTU 1500
>       |-> PHY - eth1
>       \-> VIF - Dom2 (router)
> 
> Dom 1 <-> VIF <--(bridge 1)--> VIF <-> dom2 <-> VIF <--(bridge 2)-->
> 
> Practical example:
> Dom1 generate 2 packet to be routed to bridge 2 from bridge 1.
> Packet 1: 1300 bytes DF (TCP)
> Packet 2: 400 bytes DF (TCP)
> 
> The TCP-offloading throws them together and passes 1 packet: 1700 bytes DF (TCP).
> Smart thing to do, reduces load etc.
> 
> HOWEVER
> Then it arrives at dom2, it looks at the packets, sees a 1700 byte packet, and sees the DF.
> Dom2 would put it on the bridge 2 network, fragmented, but it's not allowed, so instead it drops the packet.
> 
> I'm not sure if it's "working as designed" or if this is an unfortunate side effect.

That sounds like an unfortunate side effect. Is there a reason
that the bridge decides it is not allowed? Is that b/c of its MTU and
the 'DF' bit?

Or is the netback on the bridge the one that can't handle DF packets and
hence the bridge drops it?

> 
> Feedback welcome,
> (even "You are an idiot, of course it's  going to fail !" :) )
> Killian De Volder
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

      reply	other threads:[~2012-11-30 16:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-13 14:22 TCP Segment offloading + DF Killian De Volder
2012-11-30 16:33 ` Konrad Rzeszutek Wilk [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=20121130163339.GC5481@localhost.localdomain \
    --to=konrad@kernel.org \
    --cc=annie.li@oracle.com \
    --cc=killian.de.volder@scarlet.be \
    --cc=xen-devel@lists.xen.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.