On 2014/12/5 7:23, Jesse Gross wrote:
On Wed, Dec 3, 2014 at 11:48 PM, Du Fan <fengyuleidian0...@gmail.com> wrote:
于 2014年12月04日 06:51, Jesse Gross 写道:
My proposal would be something like this:
* For L2, reduce the VM MTU to the lowest common denominator on the
segment.
* For L3, use path MTU discovery or fragment inner packet (i.e.
normal routing behavior).
* As a last resort (such as if using an old version of virtio in the
guest), fragment the tunnel packet.
After some investigation on OpenvSwitch package, it seems before this
commit: 06021dcb "datapath: compat: Fix compilation 3.11" OpenvSwitch
package is doing GSO on its own.
rpl_ip_local_out
-> tnl_skb_gso_segment
^^^^^^^^^^^^^^^
Perform GSO in above function
-> ip_local_out
.
.
-> ip_finish_output
Which means, when over-MTU-sized skb enter ip_local_out, it's not a gso
type skb, so the stack perform ip fragmentation, and send them out.
So, over-MTU-sized skb did travel through stack into outside.
Why not dropping such OpenvSwitch level GSO operation after 3.10?
The change in 3.11 was that the tunnel infrastructure used by OVS was
upstreamed and shared by all implementations. It's not right to
perform GSO in OVS itself as it prevents the logic from being used by
other components. Breaking up the packet in OVS also eliminates some
of the benefits of GSO by shortening the optimized path and prevents
offloading to hardware.
Thanks for your explanation, I understand its background better now.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
