From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: TCP Segment offloading + DF
Date: Fri, 30 Nov 2012 11:33:42 -0500
Message-ID: <20121130163339.GC5481@localhost.localdomain>
References: <50A25798.90100@scarlet.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <50A25798.90100@scarlet.be>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Killian De Volder <killian.de.volder@scarlet.be>
Cc: annie.li@oracle.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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
>