qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 resend/cleanup 1/8] rdma: update documentatio


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3 resend/cleanup 1/8] rdma: update documentation to reflect new unpin support
Date: Fri, 12 Jul 2013 11:39:24 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

On 07/12/2013 11:26 AM, Michael R. Hines wrote:
> On 07/12/2013 01:09 PM, Eric Blake wrote:
>> On 07/12/2013 08:40 AM, address@hidden wrote:
>>> From: "Michael R. Hines" <address@hidden>
>>>
>>> As requested, the protocol now includes memory unpinning support.
>>> This has been implemented in a non-optimized manner, in such a way
>>> that one could devise an LRU or other workload-specific information
>>> on top of the basic mechanism to influence the way unpinning happens
>>> during runtime.
>>>

>>> ++++++++++++++++++++++++++++++---------------------
>>>   1 file changed, 30 insertions(+), 21 deletions(-)
>> I suggest splitting this patch into two; and cc-ing the first of the two
>> patches through qemu-trivial (since formatting cleanups can be applied
>> now, even while still waiting for a comprehensive review of the
>> algorithm in the rest of the series)
> 
> My understanding is that the reviews have completed already,
> including a very extensive test series that I performed which
> included both virt-test results and non-virt-test results from both
> myself and Chegu.
> 
> Am I mistaken?

It may have been reviewed and tested, but as you just barely posted v3
today and there is not yet a maintainer's queue with a PULL request, it
is still subject to any further review that people want to provide, and
up to the maintainer to state definitively if the further review
comments must be addressed.  It's not the end of the world if you don't
split this patch, but at the same time, splitting it makes it easier to
review, and to pick and choose which parts get backported (trivial
formatting vs. new feature).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]