Open Stack

You can use "ethtool -k eth0" to view the setting and use "ethtool -K eth0
gro off" to turn off GRO.


On Fri, Oct 25, 2013 at 3:03 PM, Martinx - ジェームズ
<thiagocmartinsc at gmail.com>wrote:

> Hi Rick,
>
> On 25 October 2013 13:44, Rick Jones <rick.jones2 at hp.com> wrote:
>
>> On 10/25/2013 08:19 AM, Martinx - ジェームズ wrote:
>>
>>> I think can say... "YAY!!"    :-D
>>>
>>> With "LibvirtOpenVswitchDriver" my internal communication is the double
>>> now! It goes from ~200 (with LibvirtHybridOVSBridgeDriver) to
>>> *_400Mbit/s_* (with LibvirtOpenVswitchDriver)! Still far from 1Gbit/s
>>>
>>> (my physical path limit) but, more acceptable now.
>>>
>>> The command "ethtool -K eth1 gro off" still makes no difference.
>>>
>>
>> Does GRO happen if there isn't RX CKO on the NIC?
>
>
>
> Ouch! I missed that lesson...  hehe
>
> No idea, how can I check / test this?
>
> If I "disable RX CKO" (using ethtool?) on the NIC, how can I verify if the
> GRO is actually happening or not?
>
> Anyway, I'm goggling about all this stuff right now. Thanks for pointing
> it out!
>
> Refs:
>
> * JLS2009: Generic receive offload - http://lwn.net/Articles/358910/
>
>
> Can your NIC peer-into a GRE tunnel (?) to do CKO on the encapsulated
>> traffic?
>>
>
>
> Again, no idea... No idea...   :-/
>
> Listen, maybe this sounds too dumb from my part but, it is the first time
> I'm talking about this stuff (like "NIC peer-into GRE" ?, or GRO / CKO...
>
> GRE tunnels sounds too damn complex and problematic... I guess it is time
> to try VXLAN (or NVP ?)...
>
> If you guys say: VXLAN is a completely different beast (i.e. it does not
> touch with ANY GRE tunnel), and it works smoothly (without GRO / CKO / MTU
> / lags / low speed troubles and issues), I'll move to it right now (is
> VXLAN docs ready?).
>
> NOTE: I don't want to hijack this thread because of other (internal
> communication VS "Directional network performance issues with Neutron +
> OpenvSwitch" thread subject) problems with my OpenStack environment,
> please, let me know if this becomes a problem for you guys.
>
>
>
>>  So, there is only 1 remain problem, when traffic pass trough L3 /
>>> Namespace, it is still useless. Even the SSH connection into my
>>> Instances, via its Floating IPs, is slow as hell, sometimes it just
>>> stops responding for a few seconds, and becomes online again
>>> "out-of-nothing"...
>>>
>>> I just detect a weird "behavior", when I run "apt-get update" from
>>> instance-1, it is slow as I said plus, its ssh connection (where I'm
>>> running apt-get update), stops responding right after I run "apt-get
>>> update" AND, _all my others ssh connections also stops working too!_ For
>>>
>>> a few seconds... This means that when I run "apt-get update" from within
>>> instance-1, the SSH session of instance-2 is affected too!! There is
>>> something pretty bad going on at L3 / Namespace.
>>>
>>> BTW, do you think that a ~400MBit/sec intra-vm-communication (GRE
>>> tunnel) on top of a 1Gbit ethernet is acceptable?! It is still less than
>>> a half...
>>>
>>
>> I would suggest checking for individual CPUs maxing-out during the 400
>> Mbit/s transfers.
>
>
> Okay, I'll.
>
>
>>
>>
>> rick jones
>>
>
> Thiago
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131025/80860066/attachment.html>