Re: [Qemu-devel] [PATCH v5 11/12] rdma: core logic

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 04/23/2013 04:59 PM, Paolo Bonzini wrote:
> Il 23/04/2013 03:55, mrhines@linux.vnet.ibm.com ha scritto:
>> +static size_t qemu_rdma_get_max_size(QEMUFile *f, void *opaque,
>> +                                     uint64_t transferred_bytes,
>> +                                     uint64_t time_spent,
>> +                                     uint64_t max_downtime)
>> +{
>> +    static uint64_t largest = 1;
>> +    uint64_t max_size = ((double) (transferred_bytes / time_spent))
>> +                            * max_downtime / 1000000;
>> +
>> +    if (max_size > largest) {
>> +        largest = max_size;
>> +    }
>> +
>> +    DPRINTF("MBPS: %f, max_size: %" PRIu64 " largest: %" PRIu64 "\n",
>> +                qemu_get_mbps(), max_size, largest);
>> +
>> +    return largest;
>> +}
> Can you point me to the discussion of this algorithmic change and
> qemu_get_max_size?  It seems to me that it assumes that the IB link is
> basically dedicated to migration.
>
> I think it is a big assumption and it may be hiding a bug elsewhere.  At
> the very least, it should be moved to a separate commit and described in
> the commit message, but actually I'd prefer to not include it in the
> first submission.
>
> Paolo
>

Until now, I stopped using our 40G hardware (only 10G hardware).

But when I switched back to our 40G hardware, the throughput
was being artificially limited to < 10G.

So, I started investigating the problem, and I noticed that whenever
I disabled the limits of max_size, the throughput went back to
the normal throughput (peak of 26 gbps).

So, rather than change the default max_size calculation for TCP,
which would improperly impact existing users of TCP migration,
I introduced a new QEMUFileOps change to solve the problem.

What do you think?

- Michael