I really encourage you to use flent with the rrul test suite when doing testing. Iperf is too simplistic and suffers from burstiness.
http://flent.org On 24 October 2016 at 20:51, 张东亚 <fortitude.zh...@gmail.com> wrote: > I am afraid my observation for openvswitch 2.6.0 is wrong, for 3.10.45, > USE_UPSTREAM_TUNNEL is also not defined, and after confirm with my > colleague, openvswitch 2.5.0 + 3.10.45 also face the same poor bandwidth > issue. > > So the problem applies for both openvswitch 2.5.0 and 2.6.0 on 3.10.45, is > vxlan receive offload feature not work on these two ovs versions desired > for this kernel? > > 2016-10-25 10:39 GMT+08:00 张东亚 <fortitude.zh...@gmail.com>: > >> Hi List, >> >> We have now testing openvswitch 2.6.0 on kernel 3.10.45, however we >> noticed there is performance drop than openvswitch 2.5.0 on the same >> kernel, which iperf can only have a 2G bandwidth for a pair of 10G links. >> >> After check the code, it seems on openvswitch 2.5.0, HAVE_METADATA_DST >> macro is used to control whether use backported vxlan tunnels, in 3.10.45 >> kernel which will result HAVE_METADATA_DST not defined, thus VXLAN receive >> offload of 3.10.45 kernel is used. >> >> However, on openvswitch 2.6.0, HAVE_METADATA_DST is renamed to >> HAVE_USE_UPSTREAM_TUNNEL, and in 3.10.45 kernel this macro is defined, >> while HAVE_UDP_OFFLOADS/HAVE_UDP_TUNNEL_SOCK_CFG_GRO_RECEIVE are both >> not defined, which make there is not VXLAN receive offload callback >> registered. >> >> Is this a desired behavior? Or we must try to update our kernel to a new >> supported one like 3.18.X. >> >> I have not find a commit that defined this yet. >> > > > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
