[openstack-dev] [TripleO][Neutron] PMTUd broken in gre networks

Rick Jones rick.jones2 at hp.com
Thu Jan 23 21:57:21 UTC 2014


On 01/23/2014 10:26 AM, Salvatore Orlando wrote:
> Hi,
>
> My expertise on the subject is pretty much zero, but the performance
> loss (which I think is throughput loss) is so blatant that perhaps
> there's more than the MTU issue. From what Robert writes, GRO definitely
> plays a role too.

It does not take much in the way of a packet loss rate to cause TCP's 
throughput/goodput/callitwhatyouwill to plummet.  Particularly if it 
means retransmission timeouts rather than fast or SACK-triggered 
retransmissions.  If the TCP connection is sending segments into a PMTU 
black hole, any send-side MTU guessing attempts will take a while to 
bear fruit.

It is an ancient presentation, but one example of the effect of 
retransmission timeouts versus fast retransmissions can be seen in one 
of the attached slides.

rick jones

>
> My only suggestion would be to route the question to ovs-discuss in
> order to get some help in precisely understanding what's going on.
> In order to understand the relationship with GRO, what are the CPU usage
> levels on the receiving node with and without GRO enabled?
>
> Salvatore
>
>
> On 22 January 2014 17:26, Rick Jones <rick.jones2 at hp.com
> <mailto:rick.jones2 at hp.com>> wrote:
>
>     On 01/22/2014 03:01 AM, Robert Collins wrote:
>
>         I certainly think having the MTU set to the right value is
>         important.
>         I wonder if there's a standard way we can signal the MTU (e.g.
>         in the
>         virtio interface) other than DHCP. Not because DHCP is bad, but
>         because that would work with statically injected network configs as
>         well.
>
>
>     Can LLDP be used here somehow?  It might require "stretching"
>       things a bit - not all LLDP agents seem to include the
>     information, and it might require some sort of "cascade."  It would
>     also require the VM to pay attention to the frames as they arrive,
>     but in broad, hand-waving, blue-sky theory it could communicate
>     maximum frame size information within the broadcast domain.
>
>     rick
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SE_372_2_99.ps
Type: application/postscript
Size: 2505688 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/c0f58ac5/attachment-0001.ps>


More information about the OpenStack-dev mailing list