qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/3] net: improve UDP/TCP checksum computatio


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 1/3] net: improve UDP/TCP checksum computation.
Date: Fri, 6 May 2016 23:31:17 +0100

On 6 May 2016 at 21:25, Jean-Christophe DUBOIS <address@hidden> wrote:
> Le 05/05/2016 16:17, Peter Maydell a écrit :
>>
>> On 23 April 2016 at 11:58, Jean-Christophe Dubois <address@hidden>
>> wrote:
>>> +    if (length < eth_get_l2_hdr_length(data) + sizeof(struct ip_header))
>>> {
>>>           return;
>>>       }
>>>
>>> -    if ((data[14] & 0xf0) != 0x40)
>>> +    ip = PKT_GET_IP_HDR(data);
>>
>> Are we definitely guaranteed that the input data buffer is aligned?
>> It seems unlikely, and if it isn't then a lot of this code (both
>> in macros like PKT_GET_IP_HDR, and open coded stuff below) is going
>> to go wrong if it tries to just access 16 bit struct fields and they're
>> not aligned and we're on a host that requires strict alignment.
>
>
> Beside a potential performance hit on unaligned data (but is it worst than
> accessing all struct members at byte level) is there any Qemu host that
> cannot handle unaligned struct members?

MIPS, for instance, also older ARM CPUs. I wouldn't be surprised
if PPC also required alignment.

> Now most network stacks run by the host or the guest should generally used
> aligned pointers for network buffers. The opposite should be quite uncommon.
> It seems most (emulated) Ethernet chip expect aligned buffers to work and
> therefore the provided pointer should always be correctly set to allow
> aligned access.

Since the buffer alignment is provided by the guest, you can't
allow QEMU to crash if it's unaligned.

We have good working support for handling loading data from
potentially unaligned buffers (and in particular loading data
of a fixed endianness), so we should probably just use it.

thanks
-- PMM



reply via email to

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