Re: [Xen-devel] TCP Segment offloading + DF

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel