Re: [Qemu-devel] memcpy speed (Re: [PATCH v2] netmap backend (revised))

[Stefan Hajnoczi]

On Thu, Jan 24, 2013 at 6:35 PM, Luigi Rizzo <address@hidden> wrote:
> On Thu, Jan 24, 2013 at 09:54:19AM +0100, Stefan Hajnoczi wrote:
>> On Wed, Jan 23, 2013 at 06:55:59PM -0800, Luigi Rizzo wrote:
>> > On Wed, Jan 23, 2013 at 8:03 AM, Luigi Rizzo <address@hidden> wrote:
>> >
>> > > > I'm even doubtful that it's always a win on FreeBSD.  You have a
>> > > > threshold to fall back to bcopy() and who knows what the "best" value
>> > > > for various CPUs is.
>> > >
>> > > indeed.
>> > > With the attached program (which however might be affected by the
>> > > fact that data is not used after copying) it seems that on a recent
>> > > linux (using gcc 4.6.2) the fastest is __builtin_memcpy()
>> > >
>> > >         ./testlock -m __builtin_memcpy -l 64
>> > >
>> > > (by a factor of 2 or more) whereas all the other methods have
>> > > approximately the same speed.
>> > >
>> >
>> > never mind, pilot error. in my test program i had swapped the
>> > arguments to __builtin_memcpy(). With the correct ones,
>> > __builtin_memcpy()  == bcopy == memcpy on both machines,
>> > and never faster than the pkt_copy().
>>
>> Are the bcopy()/memcpy() calls given a length that is a multiple of 64 bytes?
>>
>> IIUC pkt_copy() assumes 64-byte multiple lengths and that optimization
>> can matches with memcpy(dst, src, (len + 63) & ~63).  Maybe it helps and
>> at least ensures they are doing equal amounts of byte copying.
>
> the length is a parameter from the command line.
> For short packets, at least on the i7-2600 and freebsd the pkt_copy()
> is only slightly faster than memcpy on multiples of 64, and *a lot*
> faster when the length is not a multiple.

How about dropping pkt_copy() and instead rounding the memcpy() length
up to the next 64 byte multiple?

Using memcpy() is more future-proof IMO, that's why I'm pushing for this.

Stefan