From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MvoHw-0007wW-PT
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 04:23:52 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MvoHs-0007vy-44
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 04:23:52 -0400
Received: from [199.232.76.173] (port=52675 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MvoHs-0007vt-0m
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 04:23:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:23085)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pbonzini@redhat.com>) id 1MvoHr-0007LP-Na
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 04:23:47 -0400
Message-ID: <4ACDA18D.809@redhat.com>
Date: Thu, 08 Oct 2009 10:23:41 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20091007123348.GA31537@redhat.com> <4ACC9133.9060903@redhat.com>
	<20091007134853.GA9769@redhat.com> <4ACCA4AD.7050606@redhat.com>
	<20091007192127.GA3796@redhat.com>
In-Reply-To: <20091007192127.GA3796@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] qemu/pci: optimize pci config handling
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>, qemu-devel@nongnu.org


>>> What you porpose here is certainly more code than we had.
>>> So why is this a good idea?
>>
>> Because it avoids the memcpy/memcmp most of the time (when the memcmp
>> would surely succeed).
>
> Yes :) But at the cost of more code.  I don't think speed
> matters there, so less code is good.

Fine.

>>   I supposed that would also matter more as the
>> config space size increases---correct me and dismiss the patch if I am
>> mistaken.
>
> No, we'll always only look need to look at the header, whatever the size
> of the config space.  That's the point of the patch I posted - future
> proof against config space size increases, not optimization.

But fewer reads on average will not modify the header, so there will be 
even fewer memcpy with my patch when the config space will be 4k.

Paolo