On Fri, 2 Oct 2015 09:32:08 -0600 Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > On 2 October 2015 at 01:44, Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: > > Hi, > > this is an issue in Copr: > > https://bugzilla.redhat.com/show_bug.cgi?id=1268192 > > this happen rarely, but this is not first report. So I should > > address it somehow. > > > > Google say: > > http://serverfault.com/questions/338439/ssh-sessions-terminate-abruptly-with-message-corrupted-mac-on-input-disconnect > > https://ask.openstack.org/en/question/25306/slow-network-speed-between-vm-and-external/ > > > > I hesitate to turn off checksumming, but switching TCP segmentation > > offload off gains some improvements. During several measurements I > > see gain from 15.2 sec to 14.6 sec (when transferring Fedora ISO). > > But I was unable to reproduce the packet corruption. > > > > The question is - should I disable TCO on Copr machines only, or > > should I disable it in general VM spinup playbook for all our VM? > > I would turn it off on Copr machiens only. If other systems see > problems it can be hard to realize "oh that is happening on all boxes" > late in the game. If we know we have isolated it to one set of systems > it is better to do so. Yeah, I agree. Start as small as possible and move to more machines from there if it doesn't solve the issues. Also, I wonder if this is worth reporting as a bug so we could someday get a fix in openstack packages? > > > And this wiki: > > https://www.rdoproject.org/Using_GRE_tenant_networks#Offloading > > suggest to turn it off for physical hosts too. Not sure why. > > That is if we are using GRE in the networks. Are we? If we are it does > make sense because the GRE in the kernel relies on dealing with an > 'uncorrupted' packet which offloading does. Yeah, I think neutron does use gre tunnels... but I am not fully clear how. kevin
Attachment:
pgpiTO7o5kSmb.pgp
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/postorius/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
