On Sat, Dec 6, 2014 at 2:47 PM, Nicholas Bastin <nick.bas...@gmail.com> wrote: > On Fri, Dec 5, 2014 at 4:51 PM, Jesse Gross <je...@nicira.com> wrote: >> >> I don't think there is anything inherently wrong with aggregating TCP >> segments in VXLAN that are not destined for the local host. This is >> conceptually the same as doing aggregation for TCP packets where we >> only perform L2 bridging - in theory we shouldn't look at the upper >> layers but it is fine as long as we faithfully reconstruct it on the >> way out. > > > But you don't faithfully reconstruct what the user originally sent - in-path > reassembly is always wrong, which is why hardware switches don't do it (by > default, anyhow). If you configure a middlebox to do some kind of > assembly/translation/whatever work for you, that's fine, but something that > advertises itself as a "switch" or "router" should definitely not do this by > default. > > If you reassemble frames you completely obviate any kind of PMTU-D or > configured MTU that your user is using, and this breaks a lot of paths. We > completely disable all GRO/TSO/etc., but if you are able to determine that a > packet is not destined for the local host you should definitely not mutate > it.
If you look at the implementation of GRO/TSO, I think you will see that it does in fact faithfully reconstruct the original message and path MTU discovery is preserved. On Linux systems, GRO is enabled by default for all workloads - including those that do not result in local termination such as bridging. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
