On 08.07.2016 17:19, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 08.07.2016 16:17, Shmulik Ladkani wrote: >>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >>> <alexander.du...@gmail.com> wrote: >>>> I get that there is an impression that it is redundant but there are a >>>> number of paths that could lead to VXLAN or GENEVE frames being >>>> received that are not aggregated via GRO. >>> >>> There's the case where the vxlan/geneve datagrams get IP fragmented, and >>> IP frags are not GROed. >>> GRO aggregation at the vxlan/geneve level is beneficial for this case. >> >> Isn't this a misconfiguration? TCP should not fragment at all, not even >> in vxlan/geneve if one cares about performance? And UDP is not GRO'ed >> anyway. > > It's not an ideal configuration, but it is a valid one. > > Imagine TCP within vxlan/geneve, that gets properly segmented and > encapsulated. > > The vxlan/geneve datagrams go out the wire, and these can occasionally > be fragmented on the way (e.g. when we can't control the MTUs along the > path, or if unable to use PMTUD for whatever reason).
PMTUD doesn't work with vxlan in most situations anyway. But you can still control the mtu/mss with ip route and you don't need to modify the mid-hosts. > At the receiving vxlan/geneve termination, these IP frags are not GROed. > > Instead they get reassembled by the IP stack, then handed to UDP and to > the vxlan/geneve drivers. > > From that point, GROing at the vxlan/geneve device, which aggregates > the TCP segments into a TCP super-packet still make sense and has > benefits. Given the spreading with which those fragments will be send, I wonder if the GRO ontop of the tunnels will really aggregate them? Bye, Hannes
