Re: problem with outbound limiting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your clarification.
I am using 2.6.38-8-server kernel.
Will test with 3.0.0 kernel


On Thu, Aug 11, 2011 at 7:18 PM, Stefan Berger
<stefanb@xxxxxxxxxxxxxxxxxx> wrote:
> On 08/11/2011 09:39 AM, Stefan Berger wrote:
>>
>> On 08/11/2011 08:07 AM, Upendra Moturi wrote:
>>>
>>> Thanks for your reply.
>>>
>>> The patch it appears still has problem.
>>> I have changed only mtu value as 2kb instead of burst value in the
>>> network.c file
>>>
>>> With average as 2048 , burst as 2048 and peak 2048
>>> scp copied at 30-40KB/s
>>
>> All test I did were with the patch applied. I saw the throughput
>> collapsing yesterday at 2Mb mtu.
>
> Let me clarify : Yesterday I saw the throughput collapse without the patch
> applied.
>
>   Stefan
>
>>
>> I generated a file using
>>
>> dd if=/dev/urandom of=testfile bs=1024 count=409600
>>
>> I did the same test you did with 2048 without specifying a specific model
>> of ethernet card and reach 1.9MB/s using scp'ing towards remote machine.
>> When specifying <model type='virtio'/> I also get 1.9MB/s as result.
>>>
>>> With average as 4096 , burst as 4096 and peak 4096
>>> scp copied at same 30-40KB/s
>>>
>> With these numbers and using the virtio model I ended up getting a
>> throughput of 3.8Mb/s.
>>
>> The host is a 3.0.0 Linux kernel. Here's the command line output of the tc
>> command inspecting the tap interface of the VM (vnet0).
>>
>> # tc filter show dev vnet0 root
>> filter parent ffff: protocol ip pref 49152 u32
>> filter parent ffff: protocol ip pref 49152 u32 fh 800: ht divisor 1
>> filter parent ffff: protocol ip pref 49152 u32 fh 800::800 order 2048 key
>> ht 800 bkt 0 flowid :1
>>  match 00000000/00000000 at 12
>>  police 0x5b rate 32768Kbit burst 4Mb mtu 2Kb action drop overhead 0b
>> ref 1 bind 1
>>
>>
>> Maybe someone else can verify as well.
>>
>>   Stefan
>>
>>> where as earlier it was 1 MB/s.(without patch)
>>>
>>> On Wed, Aug 10, 2011 at 9:16 PM, Stefan Berger
>>> <stefanb@xxxxxxxxxxxxxxxxxx>  wrote:
>>>>
>>>> On 08/10/2011 11:20 AM, Eric Blake wrote:
>>>>>
>>>>> On 08/10/2011 09:04 AM, Stefan Berger wrote:
>>>>>>
>>>>>> On 08/10/2011 02:55 AM, Upendra Moturi wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> does this patch solve your problem? I am setting the MTU to fixed 2kb.
>>>>>> Doing tests with scp seems to indicate that this improved the
>>>>>> situation
>>>>>> -- at least for me.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> Signed-off-by: Stefan Berger<stefanb@xxxxxxxxxxxxxxxxxx>
>>>>>>
>>>>>> ---
>>>>>> src/util/network.c | 16 ++++++++--------
>>>>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>>>>>
>>>>>> Index: libvirt-acl/src/util/network.c
>>>>>> ===================================================================
>>>>>> --- libvirt-acl.orig/src/util/network.c
>>>>>> +++ libvirt-acl/src/util/network.c
>>>>>> @@ -1156,8 +1156,8 @@ virBandwidthEnable(virBandwidthPtr bandw
>>>>>>
>>>>>> virCommandFree(cmd);
>>>>>> cmd = virCommandNew(TC);
>>>>>> - virCommandAddArgList(cmd,"class", "add", "dev", iface, "parent",
>>>>>> - "1:", "classid", "1:1", "htb", NULL);
>>>>>> + virCommandAddArgList(cmd,"class", "add", "dev", iface, "parent",
>>>>>> + "1:", "classid", "1:1", "htb", NULL);
>>>>>> virCommandAddArgList(cmd, "rate", average, NULL);
>>>>>
>>>>> This hunk was just indentation; you should push the whitespace changes
>>>>> as
>>>>> a separate commit (and can push that now, under the trivial rule,
>>>>> without
>>>>> needing further review).  [It doesn't help matters that thunderbird
>>>>> botched
>>>>> the whitespace in my reply]
>>>>>
>>>>>> @@ -1202,7 +1202,7 @@ virBandwidthEnable(virBandwidthPtr bandw
>>>>>> virCommandAddArgList(cmd, "filter", "add", "dev", iface, "parent",
>>>>>> "ffff:", "protocol", "ip", "u32", "match", "ip",
>>>>>> "src", "0.0.0.0/0", "police", "rate", average,
>>>>>> - "burst", burst, "mtu", burst, "drop", "flowid",
>>>>>> + "burst", burst, "mtu", "2kb", "drop", "flowid",
>>>>>> ":1", NULL);
>>>>>
>>>>> Here's the meat of the proposed patch.  Is 2kb always valid, or will we
>>>>> run into problems on NICs that insist on traditional limits near the
>>>>> 1518
>>>>> mark?  Should it be user-configurable?  I'm reluctant to ACK this
>>>>> without a
>>>>> bit more understanding of why 2kb works, as well as feedback on test
>>>>> results
>>>>> with the patch in place.
>>>>>
>>>> Yes, I am not an exper on tc. I have seen examples with the mtu being
>>>> set to
>>>> '1' for dropping icmp traffic for example. So if a VM produces smaller
>>>> than
>>>> 2kb packets, which on traditional networks it probably should, then the
>>>> packets should go through. We could also leave out the mtu parameter
>>>> above
>>>> and it would go to 2kb by default. Check via
>>>>
>>>> tc filter show dev<ifname>  root
>>>>
>>>> The 2kb parameter doesn't explain why 2MB doesn't work, though.
>>>> Even if this wasn't the final fix, it at least 'improves the situation'
>>>> (for
>>>> me).
>>>>
>>>>    Stefan
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> libvir-list mailing list
>> libvir-list@xxxxxxxxxx
>> https://www.redhat.com/mailman/listinfo/libvir-list
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
>



-- 
Thanks and Regards,
Upendra.M

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]