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.

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).

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

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